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Track III 

Organization and Personnei issues 



Coordinator: 
Carolyn Livingston 
Tufts University 

Conirerging technologies have dictated that institutions view their 
organization's structure and use their personnel in new and better ways in 
order to manage the changing information resource function. Not only is it 
important to determine where information will be created, preserved, and 
communicated; the choices of how and who will perform the functions and 
the skills required to perform and manage the functions are critical. Topics 
covered in this track included: organizational strategies for delivering information techn ology 
services;, cultural differences among the units involved in the information infrastructure 
(computing, library, telecommunications); the need for different skills and capabilities in 
systems development staff in lig^it of new development methods; the evoMng role of the 
information center; and training and productivity issues. 
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How to Successfully Mix Oil and Water: 
or How to Get Your Programmers 
to Work with Librarians 



James J. Scanlon 
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Information professionals, as any diverse group of individuals, 
span the whole range of personality types, from the most gregarious to the 
very withdrawn. Different types of personalities are drawn to different 
professional types. We are all used to dealing with the typical police or 
bureaucratic mindset One of the primary responsibilities of any manager 
is to ensure that individuals work well in harmony. Generally, 
computing and library professionals have very different personalities. 
This paper will examine the personality differences between librarians and 
computer professionals and further examine several strategies which will 
allow them to work together. The paper will also examine the present and 
future relationships of the computer center and the library. 

The typical stereotype of the librarian is a little old lady with a bun 
on the back of her head Hiio is constantly 'shushing* patrons. According 
to the Myers-Briggs Type Inventory (MBTI), librarians typically are literal, 
search for total solutions to problems, and place emphasis on authority. 
On the other hand, computer specialists thiidc linearly, tend to search for 
the best possible fit to a problem, worrying about exceptions as they occur, 
and place emphasis on knowledge as opposed to authority when seeking 
answers. 

These two differing personality types serve their professions well. 
Librarianship is a mature profession witti a history going back to Greek 
and Roman times. Consistency of information presentation is essential 
for the librarian. One main function of the library is to provide quick and 
easy access to information for large numbers of patrons. In order to 
provide this level of access, there must be a high degree of standardization. 

One must constantly rely on rules of authority to achieve 
standardization Over the years, these rules have served librarians and the 
general public well. The majority of adults were educated in a system 
which used library methods to access informations. 

Because of the age of libraries, the dedsion-making processes have 
become very standardized. This is true of any mature institution. Mature 
institutions tend to have numerous review committees and very 
formalized dedsion*making processes which are indicative of bureaucratic 
organizations. Generally, since libraries are bureauaatic institutions, 
reliance is placed on authority as opposed to knowledge. 

On the other hand, computer professionals come from a culture 
that is very yotmg. As typical of young cultures; change is a constant. To 
deal with change, professionals must adopt coping strategies. Often these 
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coping strategies solve only a certain percentage of problems in the general 
situation and then deal with the remainder, on a case-by-case basis. 

Computei professionals, as indicative of professionals of any 
emerging field, tend to shoot from the hip and place their faith in the 
knowledge of individuals as opposed to their authority within the 
organization. Authority is a commodity that does not solve the problem 
at hand; therefore, is of little value. 

Getting these two cultures to work productively, is at times, a 
difficult and frustrating process. Constant dashes occur between the 
personality types. Procedures which make absolute sense to a librarian 
make little sense to the computer professional, and vice versa. Conflict 
seems almost inevitable because of the differences in these interpretations. 
\ case in point would be the library automation system at the University 
of Georgia. At the beginning of the author's tenure as manager of library 
automation, there was a great deal of dissention betweai the library staff 
and ttie computer staff. Shouting matches were not uncommon and little 
respect was shared between the two organizations. Over the course of 
three years, several strategies were developed to provide a better working 
relationship between these two groups. These strategies were based upon 
the following four pronged approach: 

1. Develop mutual professional respect 

2. Develop mutual understanding of operational needs of the other 
organization, 

3. Develop an identification with the positive results of the other 
organization, 

4. Good problem definition. 

At the beginning ot the project, the library staff perceived the 
computer rtaff as technicians, not as professionals. As technicians, the 
computer staffs opinions and needs carried a lower weij^ht in the minds' 
of the professional staff. The genesis of this problem is quite 
imderstandable. Often, there is no formalized training for the computer 
staff, while a professional librarian is required to earn a Masters of Library 
Science. The difference in educational requirements alone was enough to 
make this perception widespread. 

The key to overcoming this problem from the point of view of the 
computer stiff was to act with a professional demeanor in all contacts with 
the library staff. When discussing problems, the computer staff was 



instructed to deal with the problems in a professional manner. In all 
situations, * i computing staff attempted to portray the professional image 
and to refei to themselves as professionals. 

From the point of view of the library staff, the professional image of 
the computer staff was built by the management of the library. When 
talking about the computing staffs they were referred to as professionals. 
When a decision needed to be made, the management staff would often 
refer to the expertise of the technical staff. This leading by example was 
very helpful in building the image of the computer professional as a true 
professional. 

The second step was to develop a mutual understanding of 
operational needs of the other organization. Due to the diverse 
backgrounds and missions of computer professionals and librarians, there 
was difficulty understanding the professional concerns of the other 
group. As stated previously, the major interest of the library staff is to 
ensure constant and consistent access to information. It should be noted 
that the key words for library staff members are constant and consistent. 
These two words require a high degree of imiformity in operation. This 
overriding requirement for uniformity has lead to the requirement of 
librarian ^ to require solutions which allow for all of the cases. When an 
unusual cataloging problem occurs, it must be dealt with immediately. It 
cannot be handled on an exception basis, but as a part of the routine 
function of the library. 

The computer professional deals in a world where there is constant 
change. This is not only due to changes in the external environment and 
the work requirements of the supported systems, but those changes due to 
random occurrences. It is possible for a computer program to be changed 
due to the chance passing of a cosmic ray through the wrong part of a 
computer chip. Because of the extremely variable world of the computer 
professional, only the most common cases can be handled on a routine 
basis. All others must be handled on an exception basis. 

Just as the library and computer professionals must recogniz^^ each 
other as different t3rpes of professionals, this recognition has its own s >t of 
professional concerns. Discussions of all problems and solutions should 
focus on the professional concerns of both communities. The computer 
professional is concerned with the stability of the system and integrity of 
the data. On the other hand, the librarian is concerned with the accuracy 
of the data contained in the system. These two sets of concerns are often 
at odds with one anoOier. Decisions need to be made where there is a win- 
win solution regarding the professional concerns of both conununities. 
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The bottom line of each of the two professionals is the same: "The 
provision of information in a timely and accurate manner." Because the 
end is the same, each group should identify with the positive results of the 
other. A system which handles the inter-accurades of the relationships of 
serials designed by a librarian should be greeted with a high level of 
entiiusiasm by the computer staff. On the other hand, rni operational fix 
allowing for the recovery of data which is apparently lost should be 
appreciated by the library staff. 

When developing a common language between the two staffs, it is 
incumbent on the computer staff to learn the language of the library staff. 
The jargon of the librarian may seem arcane, but it has a precise meaning 
for professionals in this area. The computer staff should learn the 
language of the user to allow the computer staff to do three different 
things. It helps the computer staff to associate more closely with the needs 
of the library staff to imderstand the logic behind the language. The 
second reason is that it allows for easier problem identification and 
solutiop. It is much easier for the user to explain the problem in a 
language in which he is accustomed, than to try to explain a problem in a 
language that he really doesn't imderstand. The third reason is that it 
helps build the professional image of the computer staff because the 
computer professional has learned language of the user, and in the 
process, gained new empathy with the user. 

One method for developing this type of positive attitude toward the 
successes of other organizations is to hire staff from tho organization or to 
allow that organization the opportunity to become involved in the 
solution of a problem they are fadng. The former library staff member 
could often speak the language of the user much more easily than the 
general computer staff. An unantidpated benefit of using library staff as 
professions is to get at the other side of the questioi\s. When one of the 
computer staff would complain about a perceived library problem, the 
former library employee would say, "But you just don't understand." 
From this rather startling statement, will come a new understanding of 
the operational requirements of the library. 

Problem definition became a very big issue between the two groups. 
The library staff, being excellent problem solvers, would present problems 
in terms of solutions rather than as problems. This attempt to solve the 
problem before it was well understood generally yielded poor results. 
From the point of view of the computer professional, was that what often 
appeared to be a rational, intelligent solution to the real world would not 
work in the computer environment. 
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To assist in the problem definition, a great deal of time was spent in 
meetings where all aspects of the problem were well understood. When 
these problems were well imderstood, solutions would be discussed. This 
discussion process was often lengthy and stressful. As a result of this 
process, problems were solved which were agreeable to all parties 
concerned. By defining the problem in a manner understandable to all, a 
large step was taken in the solution of the problem. 

To make these four coping strategies work required the full 
cooperation of all levels of management in both the library and the 
computer center. It was the expressed commitment of the directors of 
both departments that full cooperation between these two would exist. 
More than a commitment was made by these two individuals; they were 
occasionally called upon to intervene in situations out of control. From 
the commitment of the senior managers, the junior management 
followed with the active encouragement and cooperation. 

In the final analysis, it was through the dedication of both 
organizations that a common professional ethic was achieved to deliver a 
service to their user community as it was needed. The professionalism of 
both organizations wa> the deciding point. The role of management was to 
demonstrate how this professional ethic could be achieved to improve 
communications between organizations. 

These steps are applicable to all groups using the service of 
computer professionals. It shotild be remembered, the main goal of the 
computer professional is to achieve succe^ through the success of the usar 
community which he/she serves. A com'^uter professional can design the 
most elegant system imaginable, provide instantaneous response time, 
and have 100% machine availability; but if the user cannot use the system, 
it is valueless. The key to a valuable system is to increase commtmication 
with the user. 



Meeting the Challenges in Computer User Support 
Don E. Gardner and Carol S, Schwob 
Florida Atlantic University 
Boca Raton, Florida 



The establishment of the microcomputer as a standard desktop tool, coupled 
with ever-increasing access to computer networks, has resulted in significant 
challenges in campus computer user support. Typically, the institutional 
response to these challenges has been shaped by the previous orientation 
of the responsible office: e.g., administrative vs. academic computing, or 
a history of mainframe vs. mini/micro support. This presentation describes 
a case study where a new "Computer User Services" department, completely 
separate from administrative computing, academic computing and the 
information center/MIS department, was created in an effort to provide a 
source o/ "application-neutrar user support. Problems and solutions are 
discussed, including the benefits of the approach and recommendations for 
those interested in pursuing a similar course. 



1 

JO 



196 



In a short ten years, microcomputers have become the single most important tool 
aside from the telephone - in most administrative offices in higher education. At the 
same time, desktop computers have provided myriad opportunities for enhanced academic 
instruction, research and public service. One result of this literal revolution is the 
emergence of a new breed of computer consultants and a variety of new offices aimed 
at providing microcomputer support to campus computing users. 

Most of these support organizations have evolved in obvious ways: for example, 
out of the traditional academic or administrative computing departments within the 
college or university. Others have become extensions or integral parts of Information 
Centers or MIS departments, where attempts have been made to adapt business concepts 
in the college setting. In every case, a series of new challenges must be addressed in 
some way: 

Guiding the transition firom a "machine-centered" to a "user-centered' 
computing environment, 

Making all campus computei users citizens (or potential citizens) of an 
integrated data network. 

Dealing with the issues of hardware and software standards. 
Managing technological change with some semblance of rationality, 
Meeting user education and training needs, and 

Maintaining effective support sub-groups (for example, network user groups, 
computer stores, computer maintenance shops, special interest groups, etc.). 

The Challenges : 

The challenge of effectively guiding the transition from a machine-centered to a 
user-centered computing environment is dependent on the extent to which campus 
computing professionals acknowledge a fundamental change in computer user status.^ 
In the old computer environment ihe mainframe (whether academic or administrative, or 
both) was at the center of activity, with computer experts working diligently to help 
users access "the machine." In the new computing enviromnent, campus mainframes are 
simply one of many computing platforms - including minis, high-powered workstations 
and microcomputers - available to help users accomplish their tasks. While some have 
been slow to recognize it, the focus has clearly shifted away from the technological bulk 



^The audion are indebted to Arthur S. Gloster, California Polytechnic - San Luis Obispo, for his presentation, 
"Establishing an Infonnation Resource Management Organizadon," in An IBM Seminar for College aiid University 
Executives, November 3, 1988, Oakland, California. 
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of major computing centers to the individual computing needs of the user, which typically 
can now be satisfied in a variety of ways. 

This being the case, the real hub of activity from a hardware standpoint becomes 
the ngtWprk. which leads to the second challenge outlined above: that of maldng all 
campus computer users citizens (or potential citizens) of an integrated data network. In 
this context it is not necessary to define an integrated network from a technological 
standpoint. Regardless of how it is achieved, providing general "any to any" device 
communication is, or will be, a requirement at most campuses.^ The focus here is on 
the difficulties associated with providing flexible, easy-to-use network access to a group 
of users with such widely disparate needs, interests and levels of sophistication. 

The challenges relating to hardware and software standards have been wid-iy 
discussed in other settings. Suffice to say here that whatever size computer user support 
staff is available, it will only be able to effectively assist users with so many hardware 
configurations and software packages. Selecting good hardware and software standards 
and making them stick is both an art and a science. 

Managing technological change with some semblance of rationality is perhaps the 
most ftiistrating challenge from a budgetary point of view. As each new generation of 
hardware and software bursts on the scene, top university administrators may have 
reason to believe that computers are a kind of "racket," with periodic payments required 
for "protection" from the dire consequences of being left out of the next level of 
technological advancement. 

Unfortunately, the pace of technological change continues unabated, although the 
rush to adopt the latest new thing appears to have slowed temporarily while users either 
work to catch up learning to use what they have, or are content with tools that are 
generally adequate. The challenge, of course, is to help identify hardware and software 
migration paths that both protect current investments, while allowing users to advance 
at a rate that needs and desires demand. 

A major part of the current investment in microcomputer technology is in training. 
Focusing on user training needs and keeping pace with them as they evolve is a major 
challenge, since it takes time and money to bring a large group of users to a significant 
level of expertise on any software package. Furthermore, each level of competence 
provides a window on further possibilities, which makes this a never ending process. At 
the same time, employee turnover insures that there will always be a need for 
introductory courses. 

The final challenges we have identified are in the areas of microcomputer 
hardware support. In spite of challenges from small businesses and the questions relating 
to unrelated business income tax, manufacturer education discounts have put most 
support centers in the position of running some kind of computer store and providing 
some level of microcomputer maintenance. Store operations range in scope from offices 
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At Florida Atlantic University, the technical challenge has been to integrate three separate data networki with 
four different protocols into a single entity ftom a user standpoint. This is being done with gateways and protocol 
converters, using TCP/IP on the fiber optic based Ethernet network. 
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which simply verify eligibility and hand out forms for users to return directly to the 
vendor, to full scale store front operations with large inventories of equipment. The ease 
with which most microcomputer hardware problems can be diagnosed and repaired 
makes maintaining some level of repair facility almost irresistible. Both kinds of 
operations have introduced a v;hole new set ot management problems and challenges in 
campus computing. 

The Case Studv: 

In 1987, a State University System of Florida re^lew team conducted a 
comprehensive study of computing at Florida Atlantic University and published its report. 
In addition to recommending a new division of Information Resource Management 
bringing the various computing departments under one cabinet-level administrator, the 
team recommended creation of a new End User Support Center supporting both 
administrative and academic computing users.^ After the new Associate Vice President 
for Information Resource Management was hired in 1988, he began immediately to 
implement many of the review team recommendations, including the creation of the new 
Computer User Services Department. 

The Associate Vice President agreed with the review team's observadons that a 
lack of coordination and direction had resulted in a wasteful and confusing use of 
resouic^s. Individuals in both computing department'^ were providing the same kinds of 
services, but often with conflicting results. The person a user would call for help 
depended almost entirely on who they knew, rather than who might be best qualified to 
satisfy their needs. The two existing centers supported di^erent networks with different 
communication protocols, in spit? of the fact that many users had both academic and 
administrative 4\inctions to fulfill. Also, different software orientations resulted in serious 
incompatibihties in sharing electronically stored information. 

While theoretically desiieable, the review team's recommendationr with regard to 
the functions of t** -^.ew Center were impossibly comprehensive. Ultimately, within the 
broad mission of providing **responsive, high quality technical support to Florida Atlantic 
University computer users,** the following ^ve specific goals were adopted: 

Provide reliable, competent advice to faculty, staff and students on 
hardware configurations, application software and network connectivity or 
microcomputers. 

Offer low-cost hardware maintenance services for microcomputer^ that will 
minimize user down time when repairs are necessary. 



^berta Maddox, Infonnarion Technology Resources tit Florida Atlantic Universitv; Report and Rgcommendattons 
(Tallahastee, Florida: State Univenity System ot Florida, September 18» 1 JB7), p. 27. 
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Provide effective low-cost training on microcomputer software products and 
use, as well as DEC VAX (mainframe) computer use. 

Coordinate campus hardware and software standards, and o tain the most 
advantageous pricing possible (through site license agreements, etc.) for 
products to assist individuals and departments minimize costs. 

Serve as a bridge between users and the technical systems people at the 
Computer Centers. Computer User Services personnel understand the 
technical foundations, capabilities and limitations of computers at Florida 
Atlantic University, and can help individuals apply computer technology to 
his/her day-to-day tasks. 

The personnel and support dollars for the new department were literally carved 
out of the existing Administrative and Academic Computing departments. Identification 
of the personnel to be reassigned was relatively easy, given that both departments were 
already engaged in the kinds of support activities envisioned for the new unit; the 
individuals involved were simply given the opportunity to be part of a combined 
operation in which they would be doing essentially the same things. The timing was 
perfect for shifting the necessary budgets, since the directors jf both of the existing 
departments had resigned just prior to the Associate Vice President's arrival. A former 
Assistant Director of Academic Computing was reassigned to head Computer User 
Services, and the department was on its way. 

Staffing Problems : 

Today, after one complete year of operation, the Computer User Services 
Department at Florida Atlantic University is firmly established and moving forward in the 
fulfillment of the goals identified above. The effort has not been without problems 
however, and some lessons have been painfully learned. 

The first of these had to do with the consequences of putting together a user 
services staff from two very different computing environments and dealing with their 
resulting "identity crisis." The composition of the original Computer User Services staff 
members was two fiom Administrative Computing, five from Academic Computing, and 
one contract employee from a Regional Data Center. 

The Administrative Computing personnel were accustomed to a one-vendor 
environment where technical problems were solved by calling in the vendor's marketing 
representative or engineer. These consultants were used to dealing with admiiiistrative 
personnel with tight deadlines - most tasks were "emergencies," and priorities were 
established based on the user's rank in the University rather than on the relative severity 
of the problem. The administrative users had generally been given whatever they asked 
for, rather than following a strategic plan for campus computing. 
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Network connections for administrative users had been accomplished by running 
individual coaxial cable from a controller in the Administration Building to the user's 
office, wherever it was located. The cost of coaxial cable and distance limitations kept 
the number of administrative network users stable. In this environment administrators 
got immediate service, and since long-term goals were never addressed, they were the 
recipients of many one-of-a-kind, support-intensive microcomputer programs. For 
example, the consultants spent a great deal of time producing customized sets of mailing 
labels for various administrative offices. 

On the Academic side, personnel were experienced in a multi-vendor environment. 
An Academic network was in place, based on Ethernet 802.3 technology. It was widely 
used and included both VAX/VMS and UNIX systems (including Hewlett-Packard, SUN 
and AT&T workstations) as well as a variety of microcomputers and terminals connected 
both directly to the network and through network servers. 

Unlike the crisis environment of the administrative users, large projects with tight 
deadlines for academicians could usually be anticipated and planned for. While 
academic users often indicated emergency status for their requests, meeting deadlines was 
generally not as critical as on the administrative side. Consequently, some of the 
academic computing consultants had a very casual attitude toward consulting and user 
problems in general. 

A major staff-related problem at the beginning had to do with salaries. There was 
a historical disparity in salaries between the two departments. Other staffing problems 
emerged during the process of assimilation. The Academic Computing Center had 
generally enjoyed a reputation as a successful, technically competent department. 
Personnel who moved from Academic Computing to Computer User Services had to give 
up some of the glory associated with their old reputation to build a new one. (The 
present location of the department is in the same building and in the same hallway as 
the Academic Computing Center so some of these identity problems still persist.) At the 
same tinie, the administrative computing personnel needed to be accepted into the group, 
and everyone had to participate in an exchange of system-specific knowledge. 

Cross-training and sharing of clientele were other initial problems. The former 
administrative consultants generally viewed administrators as THEIR clientele and were 
not anxious to take on the diversity of academic-type problems. On the other side, the 
former academic consultants were not terribly anxious to take on problems viewed as 
"office-related," such as helping someone print labels, fix envelope jams in laser printers, 
and so forth. 

Policies and Procedures ; 

Computer User Services first had to establish an organizational structure. The next 
order of business was to establish working hours and expected work routines. As 
indicated above, personnel were used to very different management styles. After general 
departmental policies were in place, procedures for each of the three sub-areas in the 
organization structure were established: Training, Maiiite^iance, and Consulting. 
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Training, One of the first things decided was that it was important to set up 
internal training criteria and procedures for staff development of the Computer User 
Services staff BEFORE attempting any expansion of training for campus computer users. 
For example, the chief maintenance person was sent to a one-week seminar to learn the 
finer points of repairing microcomputers. In turn, he was required to give a one-day 
seminar to the rest of the staff. Every staff member had to take a PS/2 and an AT style 
system apart, identify the boards and components, and put them back together. 
Following the same philosophy, other staff members attended local application seminars 
such as SAS and Desk Top Publishing, and vendor presentations on the Macintosh and 
IBM AS/400. Every other week, the department has an in-house technic?' seminar on 
pertinent topics such as LaserJet Printers (including Postscript printing), ^.^wnloadable 
fonts, network connections. Campus Network Design, UNIX to VMS gateways, using the 
Kurzweil Programmable Text Scanner, and so forth. 

With a program for internal staff development in place and functioning. Computer 
User Services proceeded to expand the training ofiered to university microcomputer users. 
Examples of the courses that were beinj, offered include: Introduction to Microcomputers 
(including DOS), WordPerfect Beginning, WordPerfect Intermediate, WordPerfect 
Advanced, WordPerfect Special Topics, DBAse, Lotus 1-2-3 Beginning, Lotus 1-2-3 
Advanced, Hard Disk Management, Backup and Restore Techniques, and Desk Top 
Publishing. 

When one of the original staff left the University to relocate out of state, it was 
very difficult to replace his skill level. During the long recruitment process, a grant was 
negotiated to partially fiind a certified trainer to teach faculty and staff. Because of the 
success of that program, the grant has been expanded to support 1.5 FTE positions. 
Computer User Services now has a part-time certified trainer with an office management 
background who concentrates on office-t^'pe seminars and courses including specialized 
topics such as WordPerfect mailmerge, printing three-up labels, among others. 

Another method used to augment the number and frequency of training courses 
offered was a significant increase in the number of courses taught by persons of expertise 
from outside the department. For example, the Computer Science Department had 
requested that Computer User Services offer mini-courses in programming languages not 
taught by their department. Consequently, part-time specialists have been hired and 
courses have been successfully offered in such topics as "C" and FORTRAN. These classes 
typically have had full registrations the day they are announced and have required 
waiting Ji^ts. 

Maintenance, An early and major imdertaking of Computer User Services was to 
set up a new Computer Maintenance Service Auxiliary to repair and maintain campus 
microcomputers and peripherals. Startini? the Auxiliary required first a list of standard 
supported hardware be produced, prices were established for agreements and repairs, a 
proposal written and presented to the President's cabinet, then the proposal went to the 
Board of Regents for approval. When the Board of Regents approved the new Auxiliary, 
a document explaining services and charges was prepared and distributed on campus. A 
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new technician position was established, which involved generating a position description 
and bringing in enough capital to cover the technician's first year salary before 
recruitment could take place. 

Although the initial charges were undoubtedly too high (based on the need to 
cover the technician's salary), the maintenance auxiliary has been successful. After the 
auxiliary was set up, a new microcomputer bum-in and installation service was instituted 
for campus users for a nominal fee. The fee also covered preliminary diagnosis and pick- 
up and delivery for warranty repairs. Whenever possible, loaner equipment has been 
provided to keep users up and running while their equipment is being repaired. 

A second major undertaking has been the set-up of a Computer Support Lab and 
Productivity Center. This Center provides demonstration equipment and software for 
students, faculty, and staff to test and to learn about computer equipment before making 
purchasing decisions. The products represented in the Productivity Center to date are 
IDM, Apple, DEC, NeXT, and Hewlett-Packard. The hardware and software available for 
demonstration will be continually updated, depending on new announcements ftom 
computer vendors. 

Part of the Productivity Center is the Florida Atlantic University Computer Store 
where vendors offer systems to students, faculty, and staff at educational discount prices. 
The 'Productivity Center also offers a method to obtain campus standard software at 
educational discount prices. In addition to providing Florida Atlantic University with a 
central place to discuss computer options, to exchange computer information, to 
demonstrate new technology, and to explore network connectivity issues, the Center 
offers other ccmces. The Kurzweil scanner is a prograiiimable text-only scanner which 
can be "taught" to read material printed in a foreign langu^^ge, or text in different printer 
fonts. There is also a graphic scanner available for use. 

Consulting . The consulting group has been the most problematic of the three 
areas within Computer User Services. The principal difficulty has been in clearly defining 
duties and then finding qualified personnel who are flexible enough to cover 
microcomputers through mainframes, and technical programming through office 
automation applications. From the beginning, the consultants were required to have 
experience with mainframe computing, with microcomputer computing as a secondary 
skiU. The philosophy was that if a consultant is expected to be able to ascertain whether 
a user computing need might best be satisfied on a mainframe or a microcomputer, the 
consultant must understand the entire computing picture. 

Other problems experienced in the consulting area include: (a) Software 
Standards . When it was announced that WordPerfect would be the campus word 
processing standard^ the choice was backed up by surveys and microcomputer magazine 
ratings. However, there were still some very unhappy Wordstar and Displaywrite users, 
(b) Cross-Training . As indicated earlier, a consulting staff concept was followed instead 
of relying on individuals to be the sole expert in any one area. All members of the staff 



^It was already the de facto standard, with approximately two thirds of the university word processixvg market 
already cornered. 
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were given primary and secondary responsibilities for supported software. This has been 
difficult to accomplish because of the demands on staff time, and the natural tendency 
for people to specialize in their favorite area. The new Productivity Center is expected 
to assist since new software and hardware will not be installed or remain on just one 
person's desktop system, (c) Help Desk . The intent has been to establish a user hot- 
line, i.e., an easy to remember number for all campus users to call with computer 
questions and problems. While the number exists and functions to a certain extent, 
employee turnover and other problems have made success in this area difficult to obtain. 

(d) Computer User Database. At the outset, the Associate Vice President directed that 
a computer user database be established to keep track of individual user hardware 
configurations and software revision levels. A software package was purchased for this 
purpose, but again, employee turnover has prevented it from being fully implemented. 

(e) Network Connectivity Issues. The campus IBM S/38 has been successfully connected 
to the campus network by a gateway system. However, until very recently, we haven't 
had the necessary staff to solve the problems associated with keyboard mapping. 

Successes in the consulting area have included: (1) establishment of a User 
Bulletin series for important announcements and distribution of university-wide 
documentation, (2) expansion of university site-licensing for microcomputer software (for 
example, in a six-month period, 570 packages of WordPerfect were distributed at a 
savings to the University of over $30,000), (3) creation of independent user groups 
(because it is not possible to support all applications, independent user groups are 
sponsored to augment the consulting stafO, and (4) opening a Computer Support Lab 
and Productivity Center where faculty, staff, and students can try out a wide range of 
software and hardware before purchasing. 

Criteria for Success : 

The following criteria were identified to measure overall success or failure: Are 
the functional goals being met? Are users receiving reasonable levels of service? Are the 
anticipated efficiencies of operation being achieved? What end user problems have been 
effectively solved or addressed? 

The scorecard so far has shown significant evidence of success: the Help Desk hot 
line logs an average 120 calls per week, the equivalent of two maintenance personnel are 
consistently busy. Computer User Services training classes are in constant demand, users 
(who are not shy about expressing dissatisfaction) appear reasonably happy, real dollars 
have been saved through more effective software site licensing, and the Productivity 
Center is open and operating. 

Lessons and Recommendati '^ns: 

Some of the obvious lessons learned were: the cliche that computing is a 
constantly changing environment is more true than ever; it is necessary to constantly 
train personnel; computer software consultants must continually be reminded it is as 
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important to SHOW the user the solution as it is to fix the problem (better yet if the 
user can be taught to fix the problem the next time it occurs); that there is no such thing 
as "settled" or "all fixed"; and there still is not enough time in the day to accomplish 
everything - which means setting priorities and sticking to them is essential. 

Some of the most conspicuous mistakes included not remembering that higher 
salaries do not necessarily make employees happy, starting out with maintenance contract 
prices too high, and relying too extensively on part-time help. 

Most notable successes included: starting v^th a clear mission statement and 
goals, hiring professional teachers vnih specialized computer training and sending the 
consultants to special training seminars and classes before allowing them to teach (it is 
a mistake to expect someone might be a good teacher just because they are expert 
programmers), separating the training group from the consulting group, and setting up 
the Help Desk hot line. 

In terms of recommendations to others, overall the Computer User Services 
Department at Florida Atlantic University has been a success. It might be argued that 
there are still significant differences between pure administrative users and pure 
academicians. However, an extensive data communications network which offers the 
same menu of services to all, effectively blurs the distinction between types of users - 
and some clearly wear both hats. The experience at Florida Atlantic has confirmed that 
there are economies to be realized, and that progress toward a university-wide 
community of computer users is an achievable goal. 
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As information systems professionals we are totaUy immersed in systems technology, at work and 
probably also at home. We are comfortable with computers and exdted about pushii^ them to the 
limite in order to solve our institution's problems. Typically, we design and buUd large centralized 
administrative systems. On the other side of the g^ are users who differ widely in their impressions of 
the systems we deliver. On the one hand, there are those vAko are not at all comfortable with 
computers and find our q^tems intimidating^ frustratmg and difficult to use. On the other hand, there 
are those who have had a variety of microcomputer experiences and find our systems lacking in 
sophistication and "personal" flexibility. 

This presentation will describe our experience at the University of British Columbia in developing a 
consistent, Hexible but realistic user interface for a student information system. We will discuss juch 
issues as screen design standards, on-line help, on-line procedure manuals, programmer creativity vs 
standards and managing user expectations. 
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L What is the User Interface? 



In a very simple sense, the user interface is everything with ^ch the user has to interact in order to use a 
computer syrtem. However, in this presentation we msh to concentrate on the kind of user interface you should 
consider for large, custom-developed systems in a mainframe environment, where you seldom find a good user 
interface. Therefore, our definition of an effective user interface has three components: iht integration of 
systems and procedures, on-line documentation and the application of consistent design principles. 



The Integration of l^stems and Procedures 

To integrate systems and procedures we must begin by deliberately designing the system and the office 
procedures at the same time. In fact, in a student system we also have to consider the student procedures, since 
students are users of a system just as much as the staff in the Registrar's Office or the faculty in the Biology 
(tepartment. Therefore, forms, pq>er flow, instructions and screen design should be seen as one "system" and 
designed as an integrated ^i^le. Our users, students included, are becoming more educated in the use of 
systems and are demanding this degree of sophistication. We, as system planners, system designers and system 
managers, must respond to this challenge and broaden our definition of the system* 

However, we must also be cautious and not attempt to automate everything in s^t. Designers should be 
taught that the initials IBM could also stand for "it's better manuaU/! In other words, e}q}anding the definition 
of the system does not imply that the computer must do all of the work. Analysts must s^ply their talents to the 
human side of the interface as well as the computer side. This be^ns ihe bricking of the g^ip. 

Another way to brieve the gsq) is to realize that tables and codes belong to the users, not to tht system. In the 
early days of ^ems everyUiing was encoded in pursuit of the elusive goal of system performance. Today, we 
encode values to improve the human performance, by saving keystrokes and time. We can only achieve this 
goal if the users can ea^ remember tte codes or easily find the correct codes. As information system 
professionals we seem to have a talent for developing cryptic codes for nearly eveiything in our environment 
(DBMS, CASE, 4GL, JCL, DFD, DED, TP, PSD, PDS, VRU-..). Somehow most of us even manage to 
remember what these codes stand for. Yet ^n we apply this talent to encoding values in our systems we 
manage to develop codes like 7-01-90-290" to mean Master of Arts in English! We still believe that numbers 
take less DASD and less CPU (there's those codes again) than ordmary English language words. In the 
broader definition of the system, this just isn't true. A consistent, meaningful, user-defined and user-maintained 
cocfing structure is a first step on the way to tddgjng the gap between the human being and that binary CPU 
deep inside the blue box. 



On*line Documentation 

The next step is to put as much of the information as people need to effectively use a system rigjit at their filler 
tips, wWch are on the keyboard ( or maybe a mouse, or even a touch screen). The way to do this is with on-line 
documentation- This dues not mean that we should rush out and take the Microsoft Word or Word Perfect files 
from which we print our manuals and put them in a file on the mamframe for users to read. In mainframe 
systems you don't have the different font sizes, boldface type, grsq>hics and other layout aids you find on a PC. 
On-line documentation has to be carefully dedgned, using very different concepts than printed manuals. At 
minimum, a good set of on-line documentation should encompass: 



- screen help 

- data element help 

- error message help 

- prompts 

- mtegrated procedure manuals 

- training tutoriab 



Mai^ PC software packages now offer these uds; why shouldn't our large mainframe systems? 
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Consistent System Design Principles 

The primary objective of apptyipg consistent system design principles is to put the user in control at all times. 
Too often we develop systems ^ch appear to users to have a mind of their owa For example, we realized that 
m the fint set of saeens we developed pressing the enter key would in some cases update the screen you were 
on and then take you to the next screen; in other cases it would update the screen you were on and then clear 
the screen for the next entrj^ and in yet another case it would update the screen you were on and re-display the 
updated record It all seemed logical to us because we knew ^ch screens were in "threads" and ^ch handled 
multiple records, but the users pomted out that there was nothing on the screen to tell them what action 
pressing enter would cause. They felt die system was in control. 

To address tiiese concerns, our interface definition insists on standard screen design principles, such as letting 
tiie users know ^t function tiiey are in, single function saeens, adherence to screen standards, menu-driven 
applications, consistent terminology for a4>tions, jn^ompts, etc, consistent navigation rules and consistent use of 
navigation aids like PF keys. We will describe later how we defined tiiese standards and rules. 



2. Why Design an Effective User Interface? 

We believe tiiat there are two key reasons wly it is necessary to design an effective user interface. These are to 
meet tiie constantly changing user expectations and tr achieve a more efficient use of resources in developing 
and supporting information systems. 



To Meet User Expectations 

The expectations ^ch users have for systems are often very different than tiiose of tiie system designers. If we 
are to meet these e)q)ectations, then we must begin to understand our users better. This process begins with 
understanding our environment. For example, UBC is a laige public university witii approximately 30,000 
students in 12 autonomous faculties, including arts, science, professional faculties and graduate studies. Each 
faculty has distinct requirements for student information and distinct i4>proaches to ^t, in other un^ersities, 
may be common procedures. Thus, a single iq[>proach to certain system functions would not meet the users* 
requirements. 

In addition, we were involved in the custom development of a student information system in a large mainframe 
environment, which entailed a migration of the system from a 1970*s batch approach to a fully interactive, on- 
line environn-ent (IDMS/MVS). We used a structured approach to phase in the new system, first developing a 
Touch Tone Telephone registration system (an i4)plication wiUi high visibility in the community), tiien 
reviewing all student systems to develop a plan for replacing the remaining old systems in several subsequent 
phases. The users ^9bo best understood tiie existing batch system therefore lacked the on-line experience to 
effectively contribute innovative ideas for a new system. Nevertiieless, we had to consider tiie needs of tiiese 
users as weD as tiio&e who were ready to make a giant leap into tiie twenty-first century. Only by carefully 
designing the user interface can you meet the expectations of such divergent groups of users. 

In any organization you wiU find tiiat the users of a system have different and changing skill levels. For 
example, we had scmie eiq)erienced people, botii faculty and stafT, who used tiie registration system frequentiy, 
understood its functionality well and were engerty awaiting more of tiie same. On the other hand, we had many 
infrequent users who lacked confidence m using computers and didn't know ^t tiie system could do for tiiem. 
There was also a large group who had been using an on-Une system on a different mainframe ^ch suffered 
from slow response time and limited functionality. They were prepared to use tiie new system, but with a 
certain vocal skepticism about its ability to do tiie job. 
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However, their lack of enthusiasm was easily ofTset by a small but growing group of PC-literate users who saw 
the PC or MAC as a solution just wait;Eig for every problem. Why couldn't the mainframe have pull-down 
menuSy pop-up dialogue boxes, multiple windows, graphics or icons and still have sub-second response time, 
they asked. 

Finally, there was the diehard group with only batch system experience. Their idea of the user interface was to 
"cram" everything on one screen, replicating their coding form which had ten or fifteen different transactions on 
the one form. 

Recognizing these different skill levels still wasn't enough. We liad to try to ensure user ownership of the 
system. The initial 6 months in the life of a system are critical for its long term success. A sense of pride and 
ownership must be developed during the design stage to ensure that user support will be there to iron oui the 
initial growing pains that any new system experiences. In order to achieve this sense of pride and ownership, 
the users need to feel that they played a key role in the design of the system and that their ideas were listened to 
and addressed in the system ii^ch is finally delivered. Developing this ownership means that the project team 
must learn to ^proach tasks from a user point of view rather than an analytical point of view. For example, a 
system designed according to all the rules of accounting principles may keep the auditor happy but will fail 
miserably if it is too complex for a clerk, the primary user, to understand. 

EtGcient Use of Resources 

Every project manager is interested in making the best use of resources in delivering a system. At first glance, 
designing a user Uiterface as we have described may ^pear to increase costs, particularly in the design and 
development stages of the project. However, a closer examination of most projects will show that a large 
portion of the team's time and the project's budget is spent on creating user manuals, crnducting training 
sessions, and distributing replacement sections of the manuals as the system is modified. Adhering to consistent 
design prindi^es and inducfing on-line documentation should reduce the number and the size of printed 
manuals, reduce the number of training sessions and reduce the cost of distributing, updatuig and replacing 
documentation. The results should be a more user-oriented system for the same resources. 

In addition, maintaining an adequate level of funding for large central systems at universities is always difficult. 
The system is expected to support the unique requirements of the individual faculties and departments, as well 
as those of the "centralized" administrative departments. Yet as soon as faculties believe they are not being 
served adequately, they may "steal" the funding to develop their own unique PC-based solutions. Developing a 
quality s^'stem from tl.e users point of view can often prevent this duplication of effort and provide cost- 
effective solutions for all users. 

Another hidden cost of training and documentation surfaces once the system has been ui production for some 
time. The frequency of user training sessions and the new releases of documentation decrease and new users to 
the system are left to strtiggle with learning the system on their own, frequently using outdated paper 
documentation. For example, the department that attended the most training sessions and collected the most 
manuals during our initial project is still the least knowledgeable on campus They frequently complain that the 
system won't do ^t they want, simply because they do not know that a feature exists. Is this their fault? 
Probably not. In hindsight, we recognized that those people were probably the least computer-literate group of 
users, had difficulty absorbing everything in the training sessions and thus had limited kr owledge to pass on to 
new staff. \^ith on-line assistance, new users will be more likely to be aware of the system features and 
continue to be satisfied with the system lotger. 
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3. How to Design an Effective User Interface 

As we have indicated, we are now developing the second phase of a student informadon q^tem. We have 
learned from our mistakes on the first phase and have begun to apply some of the concepts we have discussed 
so far. As a result of these e3q>eriences, we believe that the key factor^ in designing an effective user interface 
are establishing interface standards, ensuring extensive user involvement and recognizing the cost of training 
and documentation. 



Establish User Interface Standards 

The first step is tc develop a standards manual. This is not an easy task. We asked several senior analysts on 
the team to write position papers on each of the elements of the user interface as we defined it in section 1, such 
as help, t^le strategy, screen standards, etc These papers took into consideration some of the standards we 
had alread^f developed in Project 1, the ideas we had gsUhered from die users and the ideas we had discussed as 
a tern. The posiUon p£q>ers discussed different ways of implementii^ the concepts and tiieir technical 
consider^ons and made recommendations regarding tiie best ^)proach. We had numerous meetings witii ttie 
team leaders and several all-day sessions witii die i/^le project team and user representatives. The entire 
piocess spanned several montiis, during which time we were also completing Uie functional design of tiie 
system. 

Just ^n we thought we had a standard pinned down tiie old question, Is it a standard, a rule or a guideUnc?" 
would siuface. (We found that a standard was sometiiing you had to do, a rule was something you could break, 
and a guidehne was someUiing you could ignore!) There were always reasons why tiie standard didn't apply to a 
certan situation or became technicalty difficult to implement. At some points we wished tiiat we had had a 
standards ^peal court witii all tiie bureaucracy to discourage team members from wanting to re-open tiie 
standards discussion. What we learned, however, is tiiat a certain degree of flexibility is necessaiy botti in 
develop!!^ tiie standards and in enforcing tiiem, although knowing when to stop the research and publish tiie 
standard is difficult in this environment. 

^ ^ ^ ^^}^ ^ rcsourc;s did not permit us to implement eveiy design concept we had 

considered So we tried to set achievable goals and focus on those concepts which would best contribute to an 
u^*^^ interface at a reasonable cost. We chose to implement a meaningful coding structure witii easv 
table look-up, consistent screen design principles, screen help, data element help and a limited set of prompts. 
These provided die basis for tiie ottier aspects of tiie user interface which we hope to add in later projects. 



linsure Extensive User Involvement 

Haying developed tiie standards, we looked for ways in which to get the users heavily involved in tiie design of 
flieir system. In our first project we recognized tiie value of significant user involvement and tiierefore planned 
for user secondment, including 90% of a senior person in the Registrar's Office and some time from 
representatives of all key departments. We also established a user Advisoiy Committee witii senior 
representatives from all faculties. However, we soon discovered that mauitaining sustained user support was 
not an easy task, because day-to-day activities frequentiy took priority over ^tems development. Thus we 
looked to additional solutions for Project 1 

Baying User Involvement 

Fu-st, we "stole* an administrative staff member in tiie faculty of Education who served as our user trauier on 
Project 1 and Wred her as a systems analyst. This has worked veiy well. The team has tiie benefit of an in- 
house user, while she has gained technical expertise and is better able to recognize when a proposed functional 
solution is not technically feasible. Next, we sought to ensure stronger support from faculty members. When 
one of our best faculty representatives, a former Assodate Dean of Graduate Studies and a member of the 
Commerce faculty retired, we hired him as a team consultant on a part-time basis. He has an excellent 
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understandiiig of the administrative functions of the university as well as what will and will not be acceptable to 
faculty members in a student information system. His wealth of knowledge and sudden lack of day-to-day 
responsibilities allowed him to focus on the design of the system and therefore we improved the quality of the 
system significant^. 

Another way in ^ch we l)ought** user expertise was by assembling a development team with strong iq>plication 
experience. In addition to the extensile student i4>plication knowledge for UBC team members, we hired 
consultants with student i^pU^^^n experience, both at UBC and other educational institutions. In fact, i^n 
we take the two senior UBC people and the two senior consultants, we have a total of 47 years of diversified 
student iq)plication kno^ec^! 

However, we learned that even with such kno^edge it was not always best to assign analysts with strong 
functional experience in a particular area to that specific functioa It was sometimes difficult for analysts to 
overcome their natural indinations to impi ove efficiency by relying on their past experience rather tlum taking 
time to understand the needs of the current users. An alternative may be to assign another team member to do 
the initial research and design the ^tem, then use the analyst's functional kno^edge as a resource and for 
reviewing the design. 

Structure for Participation 

Strong, consistent user participation in the design of a ^tem is difTicult to achieve when using traditional 
approaches to systems development yAddi rely on interview sessions with many individual users followed by 
extensive written specifications and user responses. We opted for a structure which required concentrated user 
participation for short periods of time. We did this by encouraging the use of prototypes and Joint Application 
De^^-'m (JAD) workshops. 

We believe that using prototypes is the only way to design an effective system, since users typically don*t know 
what they want in a system until they have seen a version of it. Further, in order to take fuU advantage of 
prototypes they must be presented and discussed with a group of users rather than with one person at a time. 
To be successful, such group sessicms require a structure and a clear focus, ^ch JAD delivers most effectively. 
Since it is a workshop mth a team of users and onfy one analyst, a JAD generates excellent ideas and synergy 
whUe encouraging strong user partidpatioa By incorporating the creative use of technology, such as projecting 
the prototype on a screen and modi^dng and expanding it during the session, useis became even more actively 
involved in the system. However, this user involvement and improved quality of design did not come 
automatically. JADs and prototypes require careful management. 

Prototypes, by their very nature, encourage change. Prior to the JAD we had to work with the team to 
encourage them to accept this change, since most ana^ts take great pride in their work and find it difilcult to 
accept that their prototype wasn't perfect. However, after the initial JAD sessions, during which the users had 
chained the prototype many times, the team easily fell into the cycle of accepting and making changes readily. 
It was then cfifficult to bring the design to a close because there was always one more "better idea** to be 
incorporated 

Even the users got caught up in this 1)etter idea** syndrome. For example, we established our general system 
design principles well befwe the JAD sessions, as we described earlier. We thought that we had considered all 
of the options and selected the ernes which worked well in project 1 and were best suited to our users and our 
technical envirtmment Nevertheless, we still got surprised in some areas. Each of our screens had a unique 
mnemonic identifier. We thought these would be easy to remember and give some clue to where a saeen fit in 
the overall ^em. During the JADs the users decided, however, that numbers with no specific meaning were 
better way to identity screens. We were committed to deigning for the users, so we agreed to use numbers on 
the new screens and to change the names to numbers on all of the screens already built in project 1! 
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In some cases the JADs encouraged creativity beyond reaUty. Based on previous experience with PCs, the 
users requested 'friend!/ menus. They had seen menus in alphabetical sequence, menus with highlighted key 
letters for selection, menus with selecticm by number, and menus with selection based on cursor positioning. 
Each cf these q>proaches had its advantages for some group of users; therefore, tiiey wanted some aspects from 
aU four methods of selection incorporated into each menu! Needless to say, it feU to Uie project manager to 
explam why the technical limitations of MVS and the cost of programming would only permit one type of menu. 

Offsetting our enthusiasm at the d^ee of attention the users were giving to design concepts in these JAD 
sessions was the disappointment at the consistency of the user partidpatioa Even though we invited 
representatives from various departments to the JADs weU in advance, we discovered Uiat commitment to day- 
to-day activities speared to take precedence over a system being developed for Uie future. Some people yfbo 
had confirmed tiieir attendance did not attend at aU and oUiers only attended for part of the session. Even 
more frustrating, we found that some users «*o were too busy to attend the initial three-df^r development 
session attended the one-day review session and Uwn wanted to re-open previously resoNed issues because they 
had missed die initial discussioa This presented a difficult dilemma 'or the JAD faciUtator and tiie project 
manager vbo wanted die user invoh'ement, but also had a tight project schedule to meet. 

Finalty, a few guidelines on selecting user representatives are in order. Because of the size of the University, we 
found tiiat it was not feasible to im«We representatives from every faculty and department in a JAD. 
Therefore, careful selection was required to get a representative aoss-section of tiie campus. Sometimes, this 
involvwJ including some users who had traditionally been opposed to tiie system. The natural inclination was to 
wwd tiiese people, but we found tiiat it was best to get tiieir viewpoint up-front, when tiie issues couW be 
addressed, rather Uian waiting for Uie sniping to occur after the system was installed. We also found tiiat during 
tiie development process stafTuig changes occurred in key user positir:is. At UBC, Deans and Associate Deans 
are term positions. When tiie term for one of tiie Project's actively involved Associate Deans tx^td, his 
replacement had a totaUy different view of his role on tiie project and how the system should work. Managing 
such a change was a challenge for the project team. 

Even more difficul^ we discovered tiiat our greatest asset could become a potential liability. Our Registrar has 
taken a keen interest in tiie project, has attended aU of tiie JAD sessions, has displayed a great vision for tiie 
future and has shown tiiat he has an extensive knowlec^ of the current rules and regulations. He has also been 
tiie champion of tiie novice and occasional user, suggesting various concepts which would make tiie system 
resemble a PC and be more accessible to tiiese groups. His entiiusiasm and vision had an infectious quality 
wWch tiie project team enjoyed. However, he sometimes forgot that the project budget was limited, tiie scope 
had to be controUed and tiiat mainframe systems just couldn't deliver everything his PC could. We should all 
have such faith in systems development. 

Recognize the Cost of Training & Docuirientation 

Our past experience was probably not much different tiian mojt large projects in a decentralized setting. For 
Ftoject 1 we organized and ran 35 user training sessions, which cost the project team more than 100 person days 
of effort. We trained over 300 staff and faculty and tiien handed out at least 400 user manuals. These manuals 
saw more tiian 200,000 pages of p^r nui tiirough tiie Registrar's Office photocopier. The manual is already in 
its second edition and still needs revisions and improvements. Yet despite this massive effort, tiie team still 
spent more tiian 200 person days on post-implementation support, often "hand holdingf tiie same users we b"'* 
trained. 

We conduded tiiat by expending some resources early in the project to improve tiie user interface (as we ham 
descnbed) we hoped to reduce our training costs; but Uiat was not enough. We also had to address tiie issue of 
voluminous speoTicaUons, which were read once or twice by tiie programmers and then left on the shelf, «1iUe 
someone else re-produced much of tiw same information later in the user manual. We decided to take an 
evoluUonary approach, agreeing that in writing specifications we should have the ultimate goal of on-line help in 
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mind The concept was to get the team to writ'- qyedfications which could become documentati(Mi» whidi then 
would become the on-line help text In tUsivay we expected to produce a minimal user manual, perhaps in the 
form of aquU reference guide. 

The theory soimded good and was eagerly embrKxd by the team; however, w^ 

not an analysts write at the same level or with the same degree of proficiencye We had agreed that screen help 

would conftst of two parts. Rrst, a brief statement of the purpose of the screen (what it didX^li^ 

the first 'pi«e' of heto. Second, there would be three to four ^pi«^" of a description section inc^^ 

screen was to be used It was amazing to dbcom that four analysts could aU ha^ 

the word "purpose* meant In the fir^driA of our screen q>ecificadons we found that one anal^ 

describe a fairly comi^ex screen b one terse sentence, while a colleague would take four convoluted 

paragraphs. Neither oS these accurately described the purpose of the screen. 

We also found that keeinng a consistent level of bnguage and qq)roach was a problem. The [Hrogrammers and 

analysts knew what a screen was supposed to do frcm the sys^ 

write help for themselves. It proved veiydtfficult to train analysts to think like clerks. 

The answer, we found, was to have the team write the firtt draft of help and then let an experienced writer 
pc&h the product. This added to the time it took to devetop the speculcations but certaiidy improved the 
quality. 



Conclusions 

We ar2 just completii^ the design the system and have not yet begun programming r^i installation. We 
have tried to adhere to our definiticm of an efifective user interface and to invoh/e the users extensively in the 
design of their system. By this time next year we should have implementer* ^Jie first phase of the system and 
gathered some working e3q)erience with it Perhaps we will have an opportunity to ^lare the outcome of this 
experiment irith you at Cause 90. 
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OFFICE OF SYSTEM AND COMPUTER SERVICES 
IN-HOUSE MICRO COMPUTER REPAIR 
IN THE COLLEGE COMPUTING ENVIRONMENT 



Martin Fiekbe 
Donald Brusk 
Donald Sanders 
Cuyahoga Community College 
Cleveland 
Ohio 



Other than third party vendor maintenance services, what alternatives can 
College management consider for reducing the increasing costs of 
repairing and maintaining micro computing devices? What primary 
considerations should be addressed, when an alternative internal repair 
support decision is made? How do we ensure users will be provided 
service equal to or better than the service they would receive from third 
party vendors? 

The In-house Micro Repair Group at Cuyahoga Community College was 
initiated through a proposal developed by ihe College, the Office of 
Systems and Computer Services, and Systems & Computer Technology 
Corporation, the computing center facilities management organization. 
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INTRODUCTION 



Cuyahoga Community College has implemented an in-house "Micro 
Computer Repair Center" which provides faster response to user problems, 
Is more sensitive to user needs and priorities, and is more cost-effective 
than third party services. 

This session will share the experience Cuyahoga Community College 
encountered before, during and after the implementation of it's own in- 
house Micro Repair Center ...what went right, what went wrong and is 

intended to provide background or assistance to other Colleges in 
implementing similar in-house solutions. 



BACKGROUND 

In 1983/84 Cuyahoga Community College was faced with the dilemma of 
whether or not to continue paying a third party vendor approximately 
$95,000 annually for the maintenance of its terminals, printers, and micro 
related devices, (approximately 622 pieces of equipment), or find an 
alternative which would be less expensive, provide faste response and 
better service user suppor' requirements. 

During this period, whenever devices broke down or a user had a problem, a 
call was placed to the Office of System and Computer Services, (the data 
center), where it was logged by either a computer operator or a 
communications technician. The call was then forwarded to the third 
party maintenance vendor. They would respond by sending a repair 
technician to repair the device on site or return it to their service center. 
If a spare was required the college was still obligated to supply it. 

Due to the critical nature of on-line administrative transactions being 
processed, it is imperative that terminal problems be addressed 
immediately. The vendor guaranteed four hour response time, which is not 
unreasonable without a dedicated repair person on site. Quite often, this 
response time is not sufficient. When lines form at the business office, 
during registration because of equipment downtime, students get angry, 
frustrated and leave. When you depend on enrollment for your livelihood, 
this type of situation can not be tolerated. 
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The College d£ta processing environment at this time consisted of a 
Honeywell 6610 dual processor as the mainframe computer linked to three 
campuses through Honeywell DPS 6's serving as gateways. All 
Administrative Offices had Hazeltlne or Courier terminals which were the 
smart dev.ces and Lear Siegler ADM 3/5 dumb terminals. Remote printing 
was primarily done utilizing Decwriter LA 34/36 printers. The Micro 
computer environment consisted of a few IBM PC's In some offices, Apple 
It's in labs, and some donated Commodore 64's. none of which were 
network connected. Computer related hardware and software Inventory 
management was in Its Infancy, unorganized and Inefficient. 

Gameplan 

Planning was unrforway for upgrading the current network terminals to 
micro computer PC's which would provide faster response and greater 
functionality for the users. Implementing leading-edge technology, the 
college was creating more micro computer related courses of instruction, 
which meant more micro computers in the classrooms, which required 
more dollars for maintenance. All things considered, it became apparent 
tl-^at micro repair costs were going to significantly escalate. 

After requirement bids, five vendors submitted proposals for the 
maintenance of tha devices just described. Only two vendors quoted 
prices for the repair/maintenance of all terminal, micro and related 
devices, one being the then current college third party mrintenance 
vendor. 

TRANSITION 

A proposal was prepared by OSCS and submitted for an in-house micro 
repair center utilizing existing communications support personnel. 

The college decided to try experimenting with several options. The first 
option tried was an agreement with the third party vendor on a time and 
materials basis, with no overall maintenance contract, for basic 
equipment repair services. 
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The second option also included the third party vendor on time anJ 
material, but also included one of the college OSCS communications 
technicians as an in-house repair person. The vendor was primarily 
responsible for the repair of the administrative terminals and remote 
printers. The OSCS technician was responsible for repair calls associated 
with micro computers, ensuring that all calls were logged and forwarded 
to the vendor and tracked if local repair was not possible. 

The vendor charged $60.00 per hour with a two hour minimum so all calls 
cost at least $120.00... more than the worth of some devices, after parts 
costs were added. 

The technician was soon overwhelmed with repairs and %ced a backlog of 
equipment, which had been picked-up for repair. The backlog continued to 
grow and consequently the single technician with his other 
communications responsibilities, couldn't service the devices disabled the 
longest. This arrangement was unsatisfactory because the technician 
could not perform his primary duties which took priority over repairing 
micro equipment or auxiliary devices. 

OSCS Goes It Alone 

Late in FY 87/88 the college decided to modify its contract with SCT and 
add an addendum for additional personnel to initiate its' own in-house 
micro repair center staffed by two repair technicians. The staff currently 
consists of a senior technician, repair technician, and part-time student 
assistants on a continengency basis supervised by an OSCS Manager. 

The guidelines for the Micro Repair Center were that it would provide four 
hour response time, provide coverage from 7:30 A.M. to 9:00 P.M. (Monday 
through Friday) and service all three campuses, the District office, and 
other satellite sites which the college owned or occupied. 

To begin operations, policies and procedures had to be written and 
implemented, the College community had to be informed of the existence 
of the Micro Repair Center and repairs had to begin. 
The Micro Repair Center was budgeted with approximately $115,00.00 to 
buy replacement parts, leaner devices, tools, manuals, a software package 
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for Inventory and problem history management, and pay third party 
vendors for any work allocated to them. Initial staffing costs were 
budgeted at approximately $163,00.00. 

The initial Micro Repair Center staff consisted of a senior technician who 
had an extensive background In micro computers, a trainee who was 
transferred from computer operations, a student assistant with a 
knowledge of micro software, all under an OSCS Manager with an 
operations background. 

The first order of business was to prepare a suitable workplace. A phone 
number exclusively for micro repair had to be obtained and published. 
Space had to be allocated and work areas set-up. Space for parts, tools, 
manuals, in-coming/out-going devices, devices waiting for parts, others 
being worked on and office space was another concern which had to be 
addressed; there had to be space for not only the computers, but also for 
the micro repair staff. 

A form had to be designed which would serve as hard copy documentation 
of problem calls. Information had to be comprehensive enough to include 
the requestor name, phone number, problem description, date/time 
reported, date/time responded, date/time device up, repair person, 
description of work performed, time spent, parts cost, warranty 
information, leaner information, and name/date/time of outside vendor. 
This all didn't happen on the first design.. .the form became more 
descriptive as more experience was gained in the shop. Also this hard 
copy form had to stay with a device until it was returned to the user. This 
repair form is also the vehicle used to log and monitor problem history 
which is maintained on the Micro Resource Manager software package.* 

Resource Management 

At this point it's appropriate to discuss the importance of having an 
automated software package for inventory management and problem 
history tracking. 
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The college had established a policy which required all 
hardware/software purchased by anyone in the college to be logged, 
tagged, and distributed by the data center. This provided a control point 
which allowed better tracking or the increa<(ing amount of micro computer 
equipment. Prior to the establishment of the Micro Repair Center all of 
this information was entered on a data base maintained separately with- 
in the data center. The college also maintains its own data base which 
contains the same information, but not as organized or descriptive. 
Neither of these data bases contained files which could be used for 
problem reporting or maintenance information; especially labor and parts 
cost data. 

Management reporting requirements at this point were vague and 
undefined. The initial focus was on inventory control management and 
problem history. The first tracking package purchased cost $600.00 and 
after installation and use for a short period of time was found to be 
deficient in tracking labor or parts costs and wasn't sophisticated enough 
for our expanding inventory management requirements. We reviewed the 
Micro Repair Manager (MRM) package from Atrium Information Group which 
appeared to fulfill our requirements and could be upgraded to 
accommodate 15 on-line users. We purchased the basic package in 
November,1988 but production installation wasn't implemented until 
March, 1989 after an initial testing phase. Computer Associates now 
markets the MRM system. Management now focused on inventory control, 
problem history, labor tracking and parts costs statistics because OSCS 
had until July, 1989 to present facts figures, and statistics which would 
justify the decision to continue the implementation of the in-house Micro 
Repair Center. 

To install the MRM inventory data base we had to import all records first 
from the original package base and second from the college capital data 
base. The first import was not difficult because previously defined files 
and descriptions were similar. We completed importing records from the 
college capital data base, (the most difficult) in October of this year. It's 
important to note that on the data base a device is defined as anything 
which is attached to, can be attached to, or actually is a micro computer. 
For example, a keyboard is a device which we must fix or discard, but 
still have the responsibility for repairing it.. .even though keyboards aren't 
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entered on the data base because they cost less than $200.00. We still 
have to provide parts and labor costs for repairing them. 
In-house repair becomes a necessary and viable alternative when the 
number of devices begins to exceed 600. This is an approximate break 
even point, depending on equipment repair supported, to cover salaries, 
parts and equipment. Currently CCC with 2,000 micros representing a 
composite total of 8,000 devices to support, requires a cost effective 
solution. Our present in-house repair cost to support all equipment, PC's 
and other devices, is $278,000 per fiscal year. A current third' party 
verjdor quote received, of $246.00 per PC, would equal $492,000 for just 
PC's alone. Consequently in-house repair saves the College a minimum of 
$200,000 per year. To realistically look at total savings, you must 
include the cost of third party repair *or all other non-PC devices. The 
additional costs of these items, digitzers, plotters, file servers, 
printers, etc. dramatically escalates third party maintenance costs over 
just PC support. 

Estimated savings since the original implementation of the in-house Micro 
Repair Center at Cuyahoga Community College approaches $392,300 for 22 
months of service. This figure is based on prices third party vendors have 
quoted to maintain devices at one college location... then multiplied by the 
remaining devices throughout the rest of the college and compared to the 
docunr.inted costs we have incurred in the Micro Repair Center. 

An alternative method of comparing internal versus third party is to take 
OSCS's labor charge of $35.00 per hour and compare that to the minimum 
hourly rate third party vendors would have charged for the same repairs on 
site; approximately $130.00 and then add the parts costs. Most third party 
vendors are quoting $55.00 per hour on-site but they also include travel 
time and expenses in addition to this cost which equals the $130.00 figure. 
We realize significant savings (wholesale) on Apple parts as an authorized 
Apple repair center. This is achieved by having a repair technician trained 
at their school. 
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FUTURE CONSIDERATIONS 

Currently the Micro Repair staff is resident at the Metro Campus of the 
college. While this arrangement provides timely service to Metro, the 
District office, the Unified Technology Center, and a downtown ;>atellite it 
doesn't provide the same to the two campuses located outside the Metro 
Cleveland area. 

We have considered several alternatives to improve micro repair. One 
alternative is providing training, at a basic level, to Academic Campus 
Consultants located at our Western and Eastern Campuses and providing a 
small inventory of devices and parts frequently causing problems at thesa 
sites. At this point in time this alternative is still under consideration. 
Ideally, there should be a qualified repair technician at each campus who 
is linked online into the MRM system. This would allow us to generate an 
action report from the MRM system directly to the appropriate campus and 
that technician could then perform the required maintenance and update 
the MRM system. If the repair call required us to bring the device to our 
central shcp at Metro it could be picked up and a leaner dropped off by a 
delivery person msiking the rounds to all locations once a day. 

We also need to improve our service/response from those third party 
vendors which are repairing farmed out devices. Some of these repairs 
are taking in excess of two months which is unsatisfactory. Expanding our 
repair capabilities to reduce the necessity of sending equipment out 
appears to be the only realistic solution to this problem. 

We have requested the programming staff to perform an analysis of the 
"MRM" and "Progress" software packages and to determine from 
management what reports or reporting statistics are required. The 
analysis will be the impetus to generate a project producing additional 
custom reports from these two packages. 

The use of College student assistants could also be expanded into an 
academic training environment supported by and supporting the 
institution. 
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The management of the inventory database can be greatly enhanced by 
Including the Purchasing and Receiving departments in the group of online 
users of the MRM system. This would allow any purchase order relative to 
micro hardware/software to be entered by the Purchasing department at 
it's Inception, viewed for status by our office, updated by the Receiving 
department when the order came in, and updated again by our department 
when the order has been tagged, delivered and installed, and finally 
entered into the inventory database by our staff. 



CONCLUSIONS and RECOMMENDATIONS 

The in-house Micro Repair Center at Cuyahoga Community College is a new 
viable operational entity which has saved the college hundreds of 
thousands of dollars in its 22 months of operation. It provides faster 
response to user problems than a third party vendor can for the costs 
incurred, and it provides the college user community a central point 
within the college which they can call for hardware problems. An 
additional benefit of the in-house Micro Repair Center is the familia.nty 
and in most cases a relationship the users have developed with the Micro 
Repair staff in addressing their questions and problems. Having a central 
focal point within the college which monitors the pulse of micro related 
problems and micro inventory management is essential for control 
purposes and for senior college management to be able to identify its' 
micro computer resources and micro computer needs. 
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Distribating Support - DepartBental Compating Coordinators 

Jeny Sanders 
Loyola University Oiicago 
Chicago, Illiiiois 



AlMtract: End user computing appears to be successful as the talents of end users 
are increasing. This is the mission of our information centers. The mission is being 
fulfilled, and everyone is happy, right? Well, ahnost, but now we face a new set of 
concerns as decentralized processing seems to threaten the integrity of the institution's 
information resource. 

Information Systems at Loyola is sponsoring a new program to create a partnership 
and better define the relationship between it and end users. The program will 
institute an accountability called Departmental Computing Coordinator (DCC). The 
objectives of the program are to promote and harness the talents of end users, while 
maintaining the integrity of centralized systems. 



Distribotiiig Support - Departmental Compotlng Coordinators 



To say that a lot has changed in computiog over the last few years is not an unusual 
statement: conq>uting ahrays changes a lot any and emy few years. What distinguishes 
these last few years are the conq>uting capabilities that have been placed on the user's 
desktop. 

The new capabilities offer new opportunities, and computing support organizations have to 
reconsider their methods to take advantage of them. This paper describes how we at 
Loyola are doing that by means of a program called Departmental Computing Coordinators 
(DCC). 

Backgroond: Compoting at Loyola University Cliicago 

Loyola is a private, Jesuit, coeducational university with an enrollment of about 16000 in 
its ten schools and colleges. There are three campuses in tiie Chicago area, and one in 
Rome. 

Our computing enviromnent is centrally administered, and standards for microcomputer 
hardware and software have been set by the Information ^tems (IS) Division. Our 
mainframe conq>uters are IBM. There are several DEC, HP and ATT minis, and about 
2000 microconq[)uters - primarily IBM or compatible, with 100 or so ^ples. 

To date, the high level of centralization and standardization has produced a good track 
record: user satisfaction and IS credibility is relatively high. 

IS has maintained communications with users through various conmiittees as well as by 
establishing contacts in each user department In 198S, the k^ users representing the 
largest, or most compute^ ^Jtensive, departments were invited to join the IS sponsored 
"Superuser Group". 

The Superuser Group is a voluntary collaboration between Information Center staff and 
Superusers. The group meets every two months. Coordination of tiie group was turned 
over to users after the first year, and IS continues to attend group meetings. 

The Superuser Group is important because it sets the scene for the DCC program. We 
envision the evolution of our users as being k^ user to the more formalized role of 
Superuser, and then to the role of DCC. 
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Distributing Support - Departmental Computing CoonHrmtors 
Conditionf leading to the creatloB of the DCC prognun 

Before defining the DCC program, I would like to mention how we in IS saw things 
occurring at Loyola. I think that the following points sJso characterize most computing 
environments: 

* niere had been an increase in mission critical (1)et the business") systems 
operating on departmental microcomputers. 

* There is an increasing demand by the institution to see return on computing 
investments i.e. how a department has improved their services or cut costs. 

* There is an increasing requirement for specialized software. Loyola has met 
what the university had identified as a strategic level of workstatijn 
deployment, and the tools are in place that meet the need for basic 
automation - wordprocessing, spreadsheets, data management 

Departments are now requestiug software for specialized applications • unique 
to the ftmction of the department - in order to maTimiy^ the use of their 
computing equipment The evaluation, selection and use of this software 
requires knowledge of the business of the department 

* There is need for administration of new areas: 

Local Area Network administration - Loyola has 40 Local Area 
Networks installed, there are about 800 workstations connected via 
LANs. LANs need a certain level of administration performed locally. 

Data administration - IS has been engaged in a Data Administration 
planning over the last 2 years. Of course, an important objective of 
data administration is to manage data to avoid redundant and 
improve the integrity of data. Presently, however, there are over 150 
end user managed databases in departinents. Most of these were 
developed with IS; however, it is very easy to loose management 
control over end user databases. Therefore, IS needs to ensure that 
end users follow fundamental procedures in managing data in their 
databases. 



There is a desire to optimize the use of our expensive confuting resources 
by taking advantage of con^uter literate users, of whidi there are mai^ these 
days. 

Desktop computing capabilities will continue to increase, become less 
expensive and be available to a larger user audienct;. 



DistHbuUng Support - Departmental Computing Coor^naton 

Expected Benclltt of Mttfaif ip a DCC prognn 

It was apparent to IS that our end user nqpport methods would need to be upgraded to 
respond to the conditions just mentioned. For the Information Center, the primary end 
user support group, change was a familiar process. Prior change had usually meant an 
increase in central support staf^ but since it was dear that user departments possessed a 
wealth of conqmting talent and capability, we had the opportunity to create a program that 
would take advantage of that resource. 

This is what we hoped to achieve with & program that would give users defined roles as 
computing resources: 

* A best of both worlds scenario: Successful conqniting projects require an 
institution-wide (integrated databases, telecommunications, network 
compatibility, data adn^nistration) and lood (the function of the department) 
anafysis. IS is the most qualified to address the former matters, the DCC is 
the most qualified to address the latter. Projects will be partnerships. 

* The optimization of IS support through key department contacts 

* The immediate availability of first lire computing support to a department 

* The synchronization of local coiq>uting planning wi Ji institutioo-wide, long 
range computing plans 

* The creation of departmental computing standards to be maintained locally 

* The improvement of IS/User communications 

* The computing abilities of present staff will be utib'zed and redundancy in 
support services coverage wiU be reduced. The result should be a reduction 
in the rate of growth of the cost of end user conq>uting support 

Departmental Coraputing Coordinator definition 

The description of Departmental Computing Coordinator is called an "accountability". 

An "accountability" is an individual conqwnent of a job description. Usually, a particular 
job description will contain several accountabilities, eadi of which is assigned a percentage 
of time and a rating of the impact of the polbrmance of that component on the Institution. 

DCC was set up as an accountability, rather than as a job description in itself to 
accommodate different percentages of time required to fulfill the DCC responsibilities 
according to department size and level of automation. For exanq>le, in some small 
departments the DCC responsibilities can be fulfilled using a small percentage of one staff 
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DistHbuiing Support -DepalmmUU Computing Coof^ 

member's time, whfle a large department might require that a fiiU time staff member be 
dedicated as a DCC 

The same flexibility is requir i in regard to rating the impact of the DCX: responsibility. 
For exanq)le, a DCC who is responsible for workstations serving a patient monitoring 
function wiU receive a higher rating for impact than a DCC who is responsible for 
wordprocessing workstations. 

Any DCC has the responsibility to be aJiaisQQ between IS and the DOCs department This 
entails: 

* Serving as the communication link between IS and the department 

Communicates policies, standards and procedures to department staff 
Communicates user needs to IS 

* Serving as the first contact for his/her department's computing questions. 

k addition to the liaison role, a DCC might have either, or both, of these functions: 

* Admlnistratio' of departmental LANs 

At Itast one individual must be designated network .oiministratjr for a Local 
\rea Network installed at Loyola. This person wiU be the depar^aenfs 
-aison with Information Services and will be expected to fulfill the following 
roles and responsibilities: 

* Planning, with IS 

* Set-up and installatic assistance 

* Support for day to day operations 

* Training requirements coordination 

* Departmental DaU Administration 

At least one individual must be designated data admimrtrator if the 
departmniit locally maintains electronic data owned by the instigation (Data 
Adminisuatton will be the arbiter, if necessary). This person will be the 
department's liaison with the Data Adnuiistrator and will be expected to 
fulfill Jie following roles and responsibilities: 

' Planning, with IS 

* Programming (Fourth Generation Languages) 

* Documentation of data management systems 

* Data backup and recoveiy 

* Staff training requirements coordination 
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Distributing Support - Departmental Computing Coardinatan 

Hmr does a depaitaoU ddcimiM if it aeedf a DCC? 

IS presentfy handles most of the oomimting functions that have been described as future 
lespondbilities of DCX^ In mair^ cases IS will continue to do so The need for a DCC 
arises when departmentally directed computing becomes an operating requirement The 
following are g'lidelines for when DCC functions should be instituted: 

LialiOB - As mentioned previously, all DCCs will have, at least, liaison 
responsibilities. This role is raooauMnded ii^n a department's conq>uting 
requirements would best be met by identifying a key, local user. This 
recommendation would typically be made by consensus of the department head and 
IS. 

LAN Administrator - This DCC function is required if the department has a LAN. 

Data Administratoir - This DCC function is required if the department locally 
maintains electronic data which Data Administration classifies as mission-critiod 
data. The role might be reconmiended if the volume of data maintained locally is 
large, even though the data are not considered '^^ be mission-critical. 

Once the need for a DCC if detennined, ' ^ is i^ instituted? 

After IS and a department head have concluded that a DCC is needed, the department 
head will have the DCC accountability included in a revision of the job description of the 
enqvioyee selected to serve as DCC 

The revised job description will be submitted to Compensation to review for possible 
regrading of the posit' 

Pitfidls to date 

Overall, the DCC pr inini proposal has been well received. Serious pitfalls have not been 
encoimtered. The foUowing are questions and constructive criticisms directed toward the 
DCCprtposal: 



1. The Mom Work criticism is, "How come we have to make this a formal program, 
and go through the trouble of regrading jobs?" 

The response is that we have gone as far as we can go informally, and the need for 
DCCs is increa^ greatly. The Superuser group has taken responsibilities on 
volurtarify; however there is no guarantee that this will be true for most users, 
liieic responsibilities are not an official part of the job, and are not included in 
compensatioti consideration. So for it has been a matter of great cooperation and 
luck. 
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Disini Ming Support -DeiHPtnuntal Computing Coo^^ 

The Not Manageable criticism is, "We have over 250 departments! Where are you 
going to hold meetings?" 

The response is diat aldiough it is possible for die number of DCCs to grow to 
where monthly meetings become unwieldy, we'll manage communications with the 
DCCs through technology (electronic and voice mail), newsletters and small meeting 
which L« will repeat 

The How to Evaluate Positions question is, "What do we do when one Secretary 
Grade n has die DCC accountability and anodier Secretary Grade n does not?" 

The response is, from our Compensation Department, that this is not a problem. 
It is a matter similar to many others, such as when one secretary monitors a budget 
of one million dollars and the other secretary does not monitor budgets at all, or 
perhaps monitors a veiy small budget The difference in percentage of time spent 
and in in^>act will be g^ed acoordkgty. 

The Who wiUbethe Gatekeeper question is, "Who will decide who needs and who 
shall be a DCC? Won't diis have implications like faculty asking for a reduced 
teaching load because they are the DCC?" 

This is pending resolution. The resolution will probably have the department head 
request of the head of his/her division that a staff member t »me a DCC. TTiis 
request would include a written recommendation by IS and a justification accordinp 
to a formula. ^ 

The Costs question is, "Will it cost a lot to upgrade present positions by including 
die DCC accountability in job descriptions?" 

The refuse is that overall costs for computing support will be reduced institution- 
wide, although DCCs are likely to receive a small increase in pay. Cost savings will 
result from a reduction in the rate of growdi of IS end user support staff. 



Progress to date 

We are optimistic about the development of and response to the prog am so far. Support 
for the DOC program has been received from these sources: 

Informatinn Systems sees the program as a means to support the IS mission, whidi 
is: 

To provide the leadership and expertise to design, implement, support and 
manage information technologies to foster die teaching, research, and healdi 
care mission of Loyola University Chicago" 
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DUtribtabig Support - DtpartmatUU ContpiUingCc^^ 

p#.rsnnn#>l aod r^mpcnsatioii like the Program because it wiU establish iob grading 
standards to use for the increasing number of positions which include conqmting 
responsibilities. 

Su pcnisers like die program because it will provide a means to have their 
responsibilities included in their job description, and therefore to be acknowledged 
and paid for performing those re^xmsibilities. 

Most iViMirtnieiit HftflAt who are acquainted with the program support it, and a few 
have not formed an opinion. Tliose who like it feel that it gives them greater 
influence in their dqMrtmenf s oonqwting q)erations. 

Thf prpgrr'" « /rtaim^ m^tu^nt, hy *h^. Ttifnmmtmr. Systems Steering 

rnmniittee. pending resolution of the "Gatekeeper" question (#4 above). This 
committee consists of Division Heads. 

Other signs of progress are that* 

* many of the elements of the program are in practice, or are being put in 
practice. 'Hiis can also be a pitfall (see #1 above) if it is perceived that there 
is no reason to pay someone vfbo is presently doing the job voluntarify. 

* the DCC manual has been written. 

* inqrartant issues have been raised, some have been resolved, and the nq[)port 
between IS aiid departments is continually inq;>roving. 



Snmmaiy 

The Departmental Con^mting Coordinator prt^gram wiU: 

* clarify the conq>uti~)g responsibilities of department staft 

* clarify the departmental conqmting support responsibilities of Information 
Systems. 

* optimize cocqmting talent within the institution. 

* reduce the cost of end user support services. 

* contribute to Data Administration objectives. 

* establish a better rapport between Information Systems and our user 
comnmnity. 
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DisOibuiing Support ' DepattmaiuU QmputingCoonBnatan 

Conclusion 

Loyola's centralized ai>proach to information technology management has been successful. 
However, technology hss changed. Implicit in the DCC proposal is the recognition that 
Loyola's mission, and therefore the IS mission, can be better served by reassigning 
responsibilities for some areas of end user computing that IS previously controlled. This 
will encourage creative q>plication of conqmting technology to spedfic department business 
problems, and free IS resources to concentrate on the enhancement of the information 
technology infrastructure. 

There is a certain amount of risk that is invoked when reassigning responsibilities. The 
DCC program is a co(q>erative effort between IS and our users, based on mutual respect, 
and ultimately, mutual goals. The maturity of the Loyola IS organization and user 
community have created the confidence that any failures will be outweighed by the overall 
achievements of the program. With many elements of the program currently in effect, this 
has so far been the case. We are optimistic that tiie DCC program will be officially 
sanctioned in the near future, and th;>t it will meet its intended goals. 
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The University's demand for access to data makes It necessary to 
distribute administrative systems. Global strategies fundamental to 
the Implementation of distributed systems are: source point data 
capture, electronic signature approval process, data value authori- 
zation restriction and access to administrative systems by all depart- 
ments. These strategies widely disperse the responsibility for data 
Integrity to user offices. The recent design and Implementation of the 
new Student Records System at Virginia Tech employ these strate- 
gies. This discussion will explain *«^ese strategies, their Impact on the 
development ar.d distribution of administrative systems, the advan- 
tages and disadvantages of distribution, as well as user Interaction In 
development. 
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Introduction 



A totally distributed system is one which provides ail users access to data they 
need while prohibiting access to data they are not authorized to see. This ac* 
cess includes both inquiry and update capabilities. The demand for increased 
accecs to data at Virginia Tech necessitates the distribution of all new admin- 
istrative computer systems. Adoption of distribution philosophies and imple- 
mentation of the supporting strategies provides the methodology for 
accomplishing this. The rewrite of the Virginia Tech Student Records System 
combined these philosophies and strategies with extensive user interaction to 
produce a distributed system. Academic departments maintain data integrity 
which results in the role of data verification for the central student records of- 
fice. 

The Systems Development group at Virginia Tech is the primary developer of 
new administrative systems for the on*line IMS environment. This paper re- 
views the early development procedure at Virginia Tech, the philosophies and 
strategies that changed our methods, a system developed employing these 
strategies, and the conclusions resulting from an actual implementation. 

Early Development 

Development in the 1970's was initiated by a request from a user office, then 
fundamental manual procedures of the user office were observed and their 
basic needs were considered. The users were only involved in minor deci- 
sions during the design phase of a system. All other development phases of 
the project were strictly controlled by Systems Development, from planning 
functions and designing screens to testing the system. The user office was 
consulted on the contents of the screens but rarely saw them again until the 
system was demonstrated prior to implementation when they were trained and 
presented documentation defining the use of the system. 

Systems Development maintained these early systems until growth in exper- 
tise and staff led to the formation of system support groups associated with 
large user areas, such as Personnel/Payroll, Student Records, and Student 
Accounts. These groups then became responsible for system maintenance, 
minor modifications and user reports as requested. 

ccess to transactions/functions was controlled with logical terriiinal security, 
itribution was limited and generally confined to the related user area. 

Over the years, the number of terminals on the main and satellite campuses 
expanded, until in the early 80's, all administrative departments had on-line 
access to the mainframe. The University community evolved into a sophisti- 
cated computer literate society with many of the departments active in mini 
and micro computing. This growth led to demands by deans and department 
heads for greater access and stricter control of information relating to their 
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areas of responsibility. Answering this chailenge required a change in phi- 
losophies and strategies for developing new systems. 

Philosophies and Strategies 

introducing new philosophies into the university environment requires a fun- 
damep*«^l set of plans. In the 1982 CAUSE Monograph Series, Vinod Chachra 
and R jert C. Heterick presented a global strategy /or administrative systems 
In a document entitled Computing in Higher Education: A Planning Perspec- 
tive for Administrators. This publication contained the following concepts. 

• Source Point Data Capture - Data is entered via workstations in the de- 
partment of origin and transferred electronically to the destination office. 
Any requirements for approval at a higher level reroutes me document 
through the appropriate office for an 'electronic signature". 

• Value-added Data Handling - The data's electronic route depends upon a 
user's need to add information or approve a document. For those admin- 
istrators not In the hierarchical flow from source to target office, on-line 
queries and management reports are available. 

• Destination-Point Documentation Generation - Documents are printed in 
the destination office as needed for external communication and verifica- 
tion. 

• Transaction Tracking System - Events are tracked in audit trail records 
with individuals restricted to activities and data corresponding to their 
area of responsibility. 

The University adopted these global strategies for administrative systems and 
approved the 'electronic signature" - the concept of a password entered on a 
terminal screen in lieu of a signature on a document. Implementation de- 
pended on an authorization system capable of identifying areas of responsi- 
bility for a user and the required routing flow for documents. 

Virginia Tech Authorization System 

The in-house developed Virginia Tech Authorization System controls the use 
of IMS transactions through a unique authorization identifier associated with 
a user. These are established by Data Administration on request from an ad- 
ministrative user. The authorized user then contacts the administrative office 
controlling the requested transaction for access. Transactions are grouped 
according to function with access based on the need for the function. The fio- 
ministrative office is responsible for distributing the functions and assigning 
the data value mask for the user. 

The data vaiue mask defines the type of authorization and how a function is 
distributed. Tor example, the data value for the grade change function is 
composed of college, division, department, and course level (undergraduate 
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or graduate). Each person's mask for this function is based on their ievei 
withiri a coiiege. The dean of the Coiiege of Education can process any student 
talking e< course within the coiiege. The associate dean of a division within the 
coiiege can process any student taking a course within his division. This hier- 
archy continues down through the department head and his/her assistants re- 
sponsible for undergraduate and graduate courses. The mask for the 
Registrar's staff is set to aliow access to all students. 

The routing of data through the various offices is controlled with the data value 
mask and a process called ''in-basket''. Approval hierarchies are established 
for functions based on signature requirements. In the approval process of an 
electronic document, routing automatically progresses to the next level upon 
approval at a lower level. The user at each level reviews the documents to be 
approved in his/her electronic in-basket daily, much the same as processing 
paper documents. Alternate signatures are defined for each level to expedite 
the flow regardless of absenteeism in the signature hierarchy. An audit trail 
of the signatures, the original document, and any comments added during the 
approval process are stored as part of the authorization system. On final ap- 
proval, the new information becomes effective with the update of the appro- 
priate administrative data base. 

To hold users accountable for changes in a system, the authorization identifier 
and password f ^-e required on all update transactions. These become part of 
the audit trail reflecting the change. Thus accountability of data is based on 
the authorization (dentifier and the access controlled with data valued func- 
tions. 

Distributed Student Records System 

in the summer of 1985, the University administration announced the decision 
to convert from a quarter calendar system to a semester calendar system be- 
ginning Fall 1988. The existing student records system was first developed in 
the early 1970^8 and was supplemented with additional data bases throughout 
the next 15 years. Structural changes were needed based on requests accu- 
mulated over the years in addition to those required for the semester conver- 
sion. Rather than make major niodifications to an antiquated system, the 
University requested Systems Development rewrite the entire student records 
systc^m employing the policies and strategies previously described. 

Objectives 

System objectives, based on the global development strategies, were: 

• Build upon the computer literacy of the University allowing users to fully 
interact with the system 

• Capture data at the source 

• Provide accountability in conjunction with d I'a access 
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• Reduce flow of paper to and from the Registrar's office 

• Utilize electronic signature approval process for documents 

• Involve user In every phase of development 

Other objectives of the rewrite focused on paper storage reduction and system 
modularization for ease of maintenance. 

User involvement 

Due to the extensive scope of the rewrite, it was divided Into multiple sub- 
systems based on publishing and processing deadlines. Meetings with the 
University Registrar and staff to define the basic functions began the develop- 
ment of each component sub-system. A set agenda defined topic guideliner 
for each discussion and members of the Registrar's staff attended those per- 
taining to their individual areas of responsibility. 

General sessions were held with the undergraduate and graduate academic 
deans, department heads, administrative users of student information and the 
Office of Institutional Research to gather their requirements for the new sys- 
tem. These sessions were more comprehensive allowing for discussion of 
existing problem areas and requests for p' messing, access and data. Trans- 
fer of responsibilities for data entry and data Integrity from the Registrar's of- 
fice to the colleges and departments was explained and discussed. Current 
procedures and information flows in the various colleges were analyzed to 
arrive at consolidated solutions acceptable to all concerned. Meeting doc- 
umentation, recorded by a secretary as well as the analysts in attendance, 
piovided a valuable cross reference during the system design. 

Planning meetings were held with Student Systems Computer Services, the 
computer support office for all student related functions. Issues discussed in- 
cluded maintenance requirements, reporting needs, good and bad features of 
the existing system, and areas needing expansion. 

As design analysis was completed for each phase, a detailed scope of effort 
proposal was presented to student system administrators for approval. Once 
these proposals were approved, data bases were designed and, as part of 
Systems Development's methodology, reviewed by in-house data base com- 
mittees composed of selected members of Systems Development, Data Ad- 
ministration, and Student Systems Computer Services. Screens and reports 
were designed with the Registrar retaining final approval of all layouts. 
Throughout the entire rewrite, an analyst from Student Systems Computer 
Services was assigned as a liaison for the communication of requests and re- 
sponses between the Registrar's office. Student Systems, and the development 
team. 

The Registrar's staff was involved in the system testing phase of each sub- 
system. Also, selected jicademic and administrative departments across tne 
campus became test sites. Their expertise In daily processing Identified ex- 
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reption conditions in severai procedures and their perspective on the fiow of 
screens and transfer of information from one sub-system to another resulted 
in modifications which improved overaii system performance. 

Before implementation, the Registrar's office was responsible for determining 
the distribution of transactions to academic and administrative departments 
and coiieges. The needs and requirements for data accessibility for each of- 
fice were reviewed to establish the proper data value mask for each function. 

Training 

Prior to this system, a minimal number of transactions were authorized for 
departmental users. Because of the wide distribution of update capability, 
greater emphasis was placed on training for this system. To enhance this 
training, detailed user's guides were produced and distributed at training 
sessions. 

As previously mentioned^ the University Registrar's staff was trained in con- 
junction with sut>-system testing. A diverse cross section of the University 
community, r<inging from clerical staff to college deans, participated in group 
training sessions corresponding to their access needs. These were conducted 
in the weeks prior to implementation and attendance was mandatory to receive 
authori2:ation access to the new system. Slides were used to explain each 
transaCiion and familiarize the users with the type of information available. A 
question and answer period followed each presentation. 

After the system was put into production, the Registrar's staff conducted 
""hands on"" training in each user's office, giving detailed explanations for each 
transaction defined for the user. Future users of the Student Records System 
must be trained by the Registrar's staff before authorization is granted. 

Impiementation and Resuits 

The catalog sub-system was implemented in September 1986 to meet the 
publishing deadline for the Fall 1988 University Catalog. This was followed by 
the timetable sub-system in November 1987. Tht: registration modules were 
temporarily placed in production in April 1988 to conduct class registration for 
Fall. The remainder of the system conversion took place in 'uly 1988. An 
unforeseen benefit of phased implementation was the gradual introduction to 
the users of new transactions, processes and responsibilities. 

In determining the electronic routing of a process, unnecessary steps in exist- 
ing administrative procedures were uncovered. The review of manual proce- 
dures proved advantageous to the user offices and re&ulted in streamlined 
automcted processes. 
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The new system provides the University community with: 

• IncnasBd access to Information for Inquiry and update throughout the 
University, restricted by area of responsibility. Deans are now able to view 
all Information relating to students In their college as well as all courses 
taught In their college. Update functions, such as registration hours over- 
ride, bloclcs, grade changes, classroom scheduling, etc., which were pre- 
viously centre led by the Registrar, are now processed in the various 
administrative offices. 

• Distributed responsibility 'or data Integrity and timeliness. Grade changes 
are entered Into the electronic ''in-basket'' by clerical staff upon request of 
the faculty member teaching the course. The course offering department 
head Is the first step In the approval process. Grade change ""documents'" 
are then forwarded to the student's major dean with final approval granted 
by the course offering dean. At this point, the student's grade is changed 
with no required interaction hy the Registrar's office. Additional process 
responsibilities transferred from the Registrar's office include demo- 
graphic updates, major changes, academic level changes, readmlssion, 
independent study approval, and academic drops. 

• Reduced paper processing and storage. Departments enter their Timeta- 
ble of Classes modifications on-line where previously paper reports were 
corrected and returned to the Registrar's office for data entry. Grade 
change cards are no longer sent to the Registrar's office. All transcript 
Information is now stored electronically, eliminating the need to store per- 
manent record cards. Classroom usage is malntrined on the system, re- 
placing a manually updated room assignment board. 

• Enforced policy by programmatic date and function restrictions. One 
module of the system, a Dates data base, contains all processing and cal- 
endar dates for each academic term. Schedule completion programs 
check this Information before allowing modifications to a student's class 
schedule. Blocks are not allowed prior to the current date. Grade changes 
cannot be made before the current term is complete. 

Function restrictions are in place to control student and course processing 
and are achieved with the data value mask. For example, Virginia Tech 
offers 4 types of degrees: associate, undergraduate, graduate, and profes- 
sional. The Graduate School is only allowed to update student and course 
information pertaining to graduate students. Each college/department is 
restricted to their own data. This same concept controls access for on- 
campus versus off-campus processing. 
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Advantages 

Accomplishing the major objectives for the Student Records System resulted 
in numerous advantages. 

• Entry of data at its source with immediate error detection. This eliminates 
duplication of effort required when data is typed on a form prior to terminal 
entry. Errors in information are noted and the person responsible for the 
data can research and correct them. 

• Reduced errors from misreading or misinterpreting written information. 
Interpretations of hand-written forms are no longer «i problem for the 
Registrar's office reducing the time required to contact the user office for 
explanations. 

• Improved timeliness of processes. The delay due to mail schedules and 
paper shuffling is eliminated. Changes can be processed In minutes rather 
than days. 

• Modified workload for the University Registrar's staff. Other duties are 
accomplished because of reduced data entry, decreased form filing, and 
less time involved in researching errors. 

• Diminished volume of permanent paper records required. All transcript 
information is stored in the system rather than on permanent record cards. 
Cards with the audit of grade changes and major/minor changes have 
been eliminated. 

• Enhanced control of data accessibility. Distribution by function and access 
control by data value mask have resulted in more secure stud5nt records 
information. 

Disadvantages 

Post implementation studies and interviews revea.^d problems for consider- 
ation when changing to a distributed system. 

• Deans and department heads perceive additional workload for their 
areas. These offices feel they are performing services previously provided 
by the Registrar's staff with no increase in resources. The system is 
viewed as function oriented rather than task oriented thus requiring multi- 
ple transactions to accomplish a single process. 

• A higher skill level is required for administrative users. Correction of er- 
rors cannot be ignored and must be dealt with before proceeding with on- 
line transactions. Research into the cause of these errors requires 
knowledge in all areas of student records including the appropriate trans- 
actions for determining the cause of the error. 
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• VBriflcaUon for compManess and correctness has become more difficult 
with tha removal of data entry from the Registrar's office. Omissions and 
mistakes entered by the departments go undetected until they have an 
impact. For exampie, in the Timetabie of Ciasses a subtitie for a course 
was published as "Ask John what to call this". 

• Restricted access Is viewed as a limitation. Deans cannot look at the re- 
cords of a student In another college when considering a major change or 
readmission Into a new major. 

• Additional computer hart^ware and communications expenses were In- 
curred by some users to ncrease the access points to the IMS system. 
Departments whose primary processing involved the use of personal 
computers required new md/or additional mainframe connections. 

Conclusions 



Final observations 

With the support of the University, the Virginia Tech Student Records System 
was successfully Implemented as a distributed system. Based upon a study 
by Virginia Tech's Administrative Systems Review Committee, the benefits of 
distribution to the user office and the University community are numerous and 
far outweigh disadvantages revealed since implementing the Student Records 
System project. 

Establishing standards in processes across the various colleges will ease the 
impact of changes required by nutomation. The transfer of responsibilities 
from the central user office to academic administrators may require additional 
. r-'Hurces in those areas. Involvement of the user community in the develop- 
mem process needs to be encouraged to produce a workable system for all 
areas. 

Distributing a data processing system requires the definition of policies and 
strategies to govern distribution of data, the full cooperation of the University 
administration, a means of controlling access, and the support of the user of- 
fice. 

Future considerations 

All future development in the Student Records System will employ the philos- 
ophies and strategies discussed in this paper. Current discussions include tne 
availability of data on PCs for spreadsheet processing and access to the sys- 
tem by studjnts - not only for inquiries but to update items such as address 
and phone number. The capability of defining a user's access is crucial to- 
wards achieving the goal of total distribution. 
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ABSTRACT 

Converging technologies have dictated that institutions view their structure and 
use their pcn,onnel in new ways to manage the changing information and commu- 
nication resource function. Today'^ information and communication problems de- 
mand answers which are integration oriented - first for people, then for technolo- 
gies. 

A faculty/staff group developed a proposal for a needs-based, interest driven 
structure to achieve computing, communication, and human resources gorls for 
the Institute of Agriculture and Natural Resources at the University of Nebraska- 
Lincoln. The Center for Emerging Technologies (CET), which could implement 
and integrate computing, communication, and human resources, is proposed to 
bring together people and technologies. CET offers a framework for solutions to 
these Institute-wide concerns: 

(a) computing/communication services; 

(b) staff updates, training and development; 

(c) student educaJon concerning effective utilization of new technologies; 

(d) technology assessment, compuring/communication research and 
development, and ff ^.y planning; 

(e) "think tank" applications providing a visinning framework. 

Tlie proposal for CET is on-going; we are not reporting on a completed project. 
We will dc. cribc the proposal presentation process and the audiences and out- 
comes. We will report on early returns on investment as well as some of the on- 
going, in process activities lANR is now undertaking. 



* All authors contributed equally. 
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Interactive, computer based communication technologies cannot soWe all the problems 
of American higher education. Nevertheless, even in today's changing and seemingly 
chaotic educational enviit>nment, these tools advance both the practice and process of 
higlter education (Sculley, 1989). 

Many times, interactive, computer driven technology applications can be implemented 
within existing higher education structures. For structures to be successful, however, 
those itsponsible for administrative leorganization must be capable of change. They 
must see programs and themselves in new ways (Heterick, 1988; Hirschheim and Klein, 
T989). 

This paper focuses on one segment of a large, land-grant university, the Institute of Ag- 
riculture and Natural Resources OANR) at University of Nebraska - Lincoln. We will 
discuss a planning effort to substantiaMy expand the use of interactive technologies in our 
programs and attain more fully integrated applications across the campus. If imple- 
mented, this plan may require new computing and communication strategies, commit- 
ments to change, openness to risk, possibly new and untested management authority, and 
departmental reorgakiization within lANR. 

We will describe the background of the institution, and some of the computing, commu- 
nication, and human resource issues, the proposal outiining the Center for Emerging 
Technologies, and the outcomes, of the entire process including the lessons learned. 

THE BACKGROUND 

The University of Nebraska has thrcr campuses. The flag-ship campus, the University 
of Nebraska-Lincoln is a comprehensive, land-grant university with approximately 
24,000 students. Redefined as a unit in 1973, the Institute of Agriculture and Natural Re- 
liources has as its mission teaching, research and extension in agriculture, natural re- 
sources and community and family living. It is administered by a vice chancellor. lANR 
provides state-wide support of agricultural needs through a network of research and ex- 
tension centers and eighty county extension o^ices. 

To handle lANR communication and computing needs, there is a Department of Agri- 
cultural Communications providing communication support, and the lANR Computing 
Services providing computing resources. 



ERIC 



245 



Historically, the Department of Agricultural Communications is responsible for devel- 
oping brochures, editing manuscripts, producing slides and graphics, producing mediated 
programs, producing radio and television programming, and handling the lANR news 
and information functions. Computing services, including consulting, maintenance, and 
programming, ai^. carried out through lANR Computing Services. Rigid boundaries 
exist. Once written, iob descriptions are set in concrete. For each job and task, there are 
specific tools. Teniiory i^ defined. 

A blurring of jobs and functions is now occurring. In Agricultural Communications, 
artists and editors are using computer graphics packages and desktop publishing systems. 
Reporters have developed a computer based electronic newsroom. In lANR Computing 
Resources and other departments, faculty and staff are developing bro. .*urcs and newslet- 
ters using desktop publishing. Individuals aie designing visual presentations with com- 
puter graphics systr t'^s. Across the campus, in eveiy department and unit throughout 
lANR, faculty, staff, and students arc jsing the same tool, the computer, for similar com- 
munication tasks. 

Previously, each discipline had its own unique gadgets - artists with rulers and colors, 
editors with blue pencils, reporters with paper ai?d pencil, romputer programmers with 
lines of code, statisticians with formulas. The tools were job rjwific. Today the same 
engine for the tools sits on the individual's desk, linked in varying configurations. The 
tools end the engines cross previously rigid boundaries. In fact, the tools and engines are 
converging. The technologies are e^'olving into dynamical systems. 

Lines isolating "traditional*' disciplines are becoming less and less distinct. We are all 
embracing similar, "front-end" technologies in our daily tasks. Yet faculty and staff arc 
continuing to play old University roles. They perform traditional functions while assum- 
ing new, expanding roles with the tools of the computer/communication revolution. 

We still have tiie needs for which the past tools worked well, and for which die new 
tools are continuing that work. We are doing timewom activities differently, having com- 
puterized our former work tasks. By using computers, faculty are becoming more inde- 
pendent. Parallel to tiiat developing auK>nomy, faculty are growing more dependent on 
the providers of new technologies, those individuals who know how to assess and main- 
tain the new technologies, those individuals who can envision multiple and diverse uses 
of the new technologies, and those individuals who can work with the human component 
in die technological era. 

These elements of computing, communication, and human resources are problematic. 
They do not fit into existing university patterns, with simple borders, within established 
and orthodox disciplines. Such novel constituents have blurred the traditional university 
structurc. Naisbitt (1989) calls this the open square - issues with no black and white, 
simple defmition; rather they are issues full of grays, and reds, and blues, and perhapr 
many other of the 16.8 million colors. 
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THE PROPOSAL 

As an outgrowth of an lANR faculty luncheon in September 1988, we came tt)gether as 
a group. That September meeting covered issues related to the decentralization and cen- 
tralization of computing and communication services. From that discussion, we felt a 
need for the Institute to formally investigate new and emerging computing and communi- 
cation technologies. We also wanted to include equipment and personnel recommenda- 
tions to the Institute. 

We fumly believed that decentralization of computing and communications technolo- 
gies was resulting in the need for more powerful equipment and for connectivity between 
dispersed user groups. Decentralization was also crrating an enormous demand for new 
University funds to explore and implement these technology explosions within lANR de- 
partmental units. 

Based on our views of the future, we developed a short white paper. Our primary pur- 
pose was to suggest institutionalization of appropriate administrative guidelines to secure 
appropriations for items with price tags beyond the realm of individual departmental bud- 
gets. Such guidelines could include coordination of these activities by an Institute ap- 
pointed Vice-Chancellor's committee. We sent our comments to the Vice Chancellor 
and selected department heads and were ir.vlted to meet with the Vice Chancellor's coun- 
cil, composed of all the Deans of the Col^^ges. Following that presentation we were 
asked and encouraged to further explore, expand, and report v pen our ideas. 

From this charge grew a second, more comprehensive proposal. This proposal encore- 
passed the bomputing and communications, human resource, technology assessment, and 
futuring arenas at the Institute. 

Our proposal rested on a simple belief derived from the literature, from our scanning of 
the environment, and our personal feelings - that the information and communication 
challenges of today's campus demanded, and indeed* required, coordinated solutions - 
first for people, then for technologies (Prind, 1987; Dede, 1989; Heterick, 1988; Hus.ey, 
1985; UDuc, 1989; Sculiey, 1989,Seybold, 1989). 

To fully implement computing, communication, and human resources, an organization 
must assume responsibility for identifying, developing, managing, and maintaining those 
resources. To define a framework for doing this, we proposed a Center for Emerging 
Technologies in Computing, Communication, and Human Resources (GET). 

Such a Center would facilitate the use of these resources within lANR. We proposed 
the CET to support institution strengthening and human capacity-building. We also rec- 
ommended that CET results be evaluated in both human and technical terms. 

What is The Center for Emerging Technologies? We envisioned CET as a needs- 
based, interest driven structure to achieve computing, communication, and human re- 
sources goals within the Institute of Agriculture and Natural Resources. CET is a formal 
response and an institutional commitment to the integration of people and technologies. 
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Steele (1989) pointed out that opportunity will rarely reside in the traditional practices 
of simplifying, separating, and operating exclusive entities. Integration will be the key 
since problems cross lines of interest and authority. 

The Center for Emciging Technologies was proposed to address several Institute-wide 
needs including: 

(a) computing and communication services; 

(b) professional and organizational development focusing lANR staff and organizational 
development activities; 

(c) technology assessment, computing and communication research and development, 
and facility planning; and 

(d) "think tank" applications providing a framework for visioning. 

The Center for Emerging Technologies in Computing, Communication, and Human Re- 
sources would create an environment that: 

- refocuses efforts toward priorities as outlined in lANR's Strategic Plan; 

- allows fordoing new things, not just computerizing old processes; 

- analyzes positive and negative impacts of the integration of technology and people; 

- streamlines the support, consulting, and maintenance roles in lANR; 

- allows for "think tank" capabilities; 

- encourages curiosity and risk taking. 

The CET would address perceived barriers and fortify multi-disciplinary ties between 
computing, communication, and human resources. 

The CET structure flows from the functions of existing communication and computing 
programs and innovative /(imrm^ activities. 

Clientele 
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CET's four major areas or divisions are outlined and described below: 

A. Computing and Communication Services-integration of computing, communica- 
tion and information delivery services: 

Computing consulting and support services would include au.iinistrative computing 
(budgeting, accounting, and requisitions, student records, drop and add, registration, re- 
search databases, and personnel), mainframe computer support, computer programming 
support, and computer labs (development, expansion, and monitoring). 

CET communication services would comprise production of visuals, signs/displays, 
printing facilitation and distribution, photography. Consulting communicators would 
work on a inter- and multi-disciplinary basis within lANR to facilitate communication 
marketing, strategic planning, and production efforts 

Both communication and computing components would also involve maintenance capa- 
bilities, networking, equip^^ent loan (computer and audio-visual equipment), large equip- 
ment facilitation (siting within units), communication and computer training and support 
on campus and at District Centers. 

This component results from the integration of communication and information deliv- 
ery services. A blurring of the barriers separating previous functions drives this natural 
marriage of services. 

Computing, for example, was once separated between mainframe data processing (DP) 
shops and non-computer users. You either u^ed computers through the DP shop, or you 
did not use them at all. This evolved into a mainframe environment which began support- 
ing personal computer users only among the innovative. Today there are few, if any non- 
computer users on staff, most have access to intertwined networks, and none who particu- 
larly car^ whether the computer service represents a mainframe or personal computer op- 
eration. A blurring of the previously well defined confines of computing types vs. non- 
computing types has occurred. 

Another good example of biurring can be found in the academic computing arena and 
alternatively the arena for administrative computing. In the very recent past, these two 
entities were quite separate. Many institutions, including the University of Nebraska, 
have distinct computing organizations for these two segments of our school's support 
components. 

Today, however, a blurring of tne barriers separating these entities is rapidly occurring. 
Review any issue of Academic Computing or T.H.E. Journal to see programmic exam- 
ples of vast blurring. Faculty are requiring access to their student advisees' rccordr, elec- 
tronic mail needs to travel over networks to administrators as well as educators, depart- 
mental accountants are accessing budgeting and requisitioning programs via campus net- 
works, and yet they still expect electronic access to all the academic programs and aca- 
demic computer networks. The list of mutual needs is growing daily. Now, instead of 
bein<^ able to conduct business within a DP shop, or across a proprietary network, the 



ERLC 



6 «i 



249 



academic and admf nistrative information organizations arc utilizing similar network com- 
ponents, as they're now being required to serve identical user bases distributed across the 
campuses. This blurring of boundaries is requiring the movement to similar computing 
platforms or transparent information exchange between varieties of vendor platforms. 

Distributed computing has fostered the growth of local desktop publishing, newsletter 
productions, graphic design operations, and the use of multi-media technologies through- 
out many campus departments, ^^^ene once the department of information or communi- 
cation was relied upon for nearly all production and dissemination of materials, more and 
more production is being done "in-housc". Questions to our communications specialists 
from faculty and staff are now highly technical, computer oriented and many times impa- 
tiendy voiced. No longer are these professional communicators advising solely on con- 
tent or appearance, but more on how to stretch the limits of the myriad of graphics and 
text hardware and software components springing up throughout the campus. 

Secure, protective borders of responsibilities are disappearing. These two groups of 
service and educational professionals are finding themselves dravring from the same well 
and watering the same masses. The proposed component consisting of communications 
and computer services personnel, will enhance everyone's ability to serve more coopera- 
tively and thus effectively. 

B. Professional and Organizational Development - focus of lANR staff and organi- 
zational development activities: 

The human component of CET includes activities revolving around faculty renewal, 
staff leaves, re-tread shop, staff training, student education and module development, 
grantsmanship, fiindraising, needs assessments, interest inventt)ries, development of re- 
cruitment and retention strategies, links to outstate educational facilities, research activity 
such as impacts of change, higher education, administration, etc. 

Professional and Organization Development activities will cut across many of the Com- 
puting and Communication practices. Botii groups will have to be closely coordinated 
to ensure targeted, specific programs for faculty, staff, and students. 

C. Technology Assessment - facilitation of the research, development and evaluation 
of new computing and communications technologies: 

This component would be responsible for the development of the Institute as a Beta 
and pilot test site for emerging computing and communication technologies. It would 
also work on planning functions for lANR computing and communication resources, 
such as consultation on new buildings, student computing labs, and networking. 

Other activities would include outreach to Nebraska industries and business on comput- 
ing and communication consultation, and research on communication activities and out- 
comes, including qualitative audience analysis. 
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D. Think Tank - framework for visioning and futuring: 

This component is a future oriented, scanning group that encourages new ideas. Activi- 
ties will focus on establishing environments for planning, modeling, and prototyping 
ideas, analyzing positive and negative impacts of suggesting ideas via cross impact ma- 
trix analysis, and creating a body of resource materials for sharing. 

Interaction will take place in interdisciplinary and multidisciplinaiy ways and would 
allow individuals from differing views and/w areas to combine positive talents. Thus, 
we feel that human capacity for problem solving and futuring will be developed, refined, 
and enlarged through the think tank and the human resource component. The Think 
Tank is to provide the environment for alignment (Naisbitt and Aburdene, 1985). 

On coming into the think tank, people's initial expectations will be "challenged/reset"; 
people will have or be exposed to some fundamental training in futuring before they 
come into the think tank. Follow-up activities will be developed as part of the experi- 
ence. A process of constant futunng will be developed. 

An attempt will be made to avoid elitism or the charge of snobbery. The think tank 
should not divide people into categories. Rather it should be used to bri ; people to- 
gether. However, it not a counseling center for opposing views. It is ^ess ori- 
ented, futuring activity. The think tank encourages responsibility for thinKmg. It invites 
moving information around and depends on open environments, minimum boundaries, 
and high levels of people interest. 

A lot of think tank activities will take place away from normal duties and environ- 
ments, i.e., retreat type of settings. Yet a lot of activities can be done in the current physi- 
cal environment. The challenge will be to change the mental environment of faculty, 
staff, and students. Initial training and challenging of expectations will be used to change 
that mental environment. New norms will be established when people come into the 
think tank. 

EXPECTED IMPACTS 

What are the expected impacts of the CET? Based on our examination of the I ANR 
needs and expectations, CET objectives and activities, the following impacts were pro- 
jected: 

1. Addresses the organizational challenges of lANR Computing Services and the De- 
partment of Agricultural Communications. It brings together the emerging technologies 
and the support staff of computing and communication. 

2. Places responsibility for the management of support services with professional/m na- 
gerial staff, and not faculty. This arrangement would free faculty for consulting and aca- 
demic activities supporting CE1\ 
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3. Focuses on human resource needs in response to accelerating changes. 

4. Provides a smicture for "re-careering" and "opportunity offering" through the Profes- 
sional and Organizational Development component. 

5. Eliminates duplication of services. 

6. Provides structure for multi-disciplinary interaction between GET and departments 
in content related development activities. 

7. Eliminates the encounter between centralization and decentralization service con- 
cepts by advocating that a mix of both is a more realistic approach. 

8. Recognizes the need for strong, distinct authority in content areas of computing, 
rommunication, and human resources for the purpose of institutional structure and func- 
tions of leadership, development, and futuring. 

9. Creates temporary disequilibrium among those direcUy impacted by proposed 
changes, an addressable administrative impact 

10. Creates unit administrative issues including transfer of personnel and services, and 
tenure concerns. 

OUTCOMES 

The CET is an idea whose time has not yet come to lANR. Nevertiieless, the changes 
envisioned in the CET and its proposed restructuring remain viable. 

We know that order, rationality, predictability, and impersonal modes of operating arc 
all b^^rriers to innovation and creativity in institutions of higher education. Change, of 
the scale offered by the CET proposal, runs counter to institutional needs of orderliness 
and predictability. While it can be planned and controlled, change requires new behav- 
iors, different interactions, altered assumptions, and revised attitudes. 

Given that, several ideas from the CET proposal and the earlier White Paper have been 
explored and implemented. These include the following: 

1. Administrative calls for i,w j equipment requests and acquisitions have been priori- 
tized based upon lANR-wide, interdisciplinary utilization. 

2. The Office of Professional and Organizational Development (OPOD) was in the pro- 
cess of independent formulation during this proposal's development. OPOD is now un- 
dertaking human resource activities encompassing recarccring, technical assistance, and 
retraining. 

3. Several lANR task forces have been formed campus-wide to review and forecast pol- 
icy on databases, graphics, and desktop publishing activities. 

4. Think Tank applications have been reconceptualized to include futuring. One mem- 
ber of our group has been asked to work in multi-disciplinary. Institute futuring activities. 
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5. An informal lANR-wide futures group of faculty and staff is meeting on a regular 
basis, twice a month. In addition, the Department of Agricultural Communicauons has 
developed a futures committee. 

Sikes, Schlesinger, and Seashore (1974) ^int out that all universities have obstacles to 
creativity and imagination. These involve order, rationality, predictability, and imper- 
sonal modes of operating. '^Change to some degree runs counter to orderliness and pre* 
dictability; it can be planned and controlled but inherently it calls for new behaviors, dif- 
ferent interactions, altered assumptions, and revised attitudes. One cannot always be sure 
where it Mil lead" (p. 39). 

We faced many of these obstacles to implementation and change. From our experi- 
ences, we learned several things, some of which we would like to share. For example: 

1 . Don't take a hardball to a Softball game. We lacked experience in working with the 
system. We assumed that good ideas sold themselves. We did not include department 
heads or higher level administrators eaily enough in the design and development process. 
Basically, we handed them a "finished** product in the GET. We did not get an advocate 
to champion our cause. We mistakenly believed that administrative interest (which we 
had) was tantamount to strong support and quick implementation. 

2. Show me yours. We had difficulty in assessing the reactions that others would have 
with the GET, The very nature of the GET makes it awkward to pilot or develop a proto- 
type. Without a visible, working model, widespread faculty interest or serious adminis- 
trative support has not been forthcoming. 

3. Wash your mouth. We may have been too explicit v en we wrote our second paper, 
the comprehensive opus detailing the GET. We played out our ideas and put our flndings 
in writing, without options. We did not look for models or provide alternatives. We 

uld have presented two or three scenarios representing different degrees of change. 

4. Don't expose your backside without suntan lotion. While the administration was in- 
terested in our ideas, they did not officially sanction them. We should have asked for let- 
ters and verbal approval with copies to selected faculty, in particular the department 
heads. 

5. Share everything. We did not involve key people on campus. Even though we used 
a multi-disciplinaiy team approach, we needed a broader base of support for systematic 
change, and for the development of the GET in particular. 

We did not account for alignment. Once we had the vision, we needed to attract peo- 
ple who could help realize it (the vision) by adopting it as their own and sharing the re- 
sponsibility for achieving it. 

6. Tims is on my side. We might have arranged time for people to spend studying the 
proposal. This might have helped broaden the process and understanding of the changes 
envisioned, '^.hange could probably come about sooner and more radically if the adminis- 
tration had re eiv^ the message from more people directly and indirectly affected by the 
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change. But we acted swiftly, turned data around quickly, and in the pnxxss, did not 
give many of the audience with whom we were communicating enough time to digest our 
ideas or offer suggestions. 

CONCLUSION 

We realize that success or failure of change ultimately rests with the people who are 
being asked to change - their attitudes, understandings and their support. This takes time. 
Aldiough parts of die GET proposal have gained acceptance, and indeed have been imple- 
mented, otfiers remain as challenges. 
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